In fact, you can't actually rely on libc being any particular way, either - but that's what autoconf is for. When you create a portable upstream software package that doesn't make any assumptions about where it's going to be installed, you can still rely on both the existence and the (POSIX subset) semantics of ls! But Python? No way. And that 'Linux' target, almost always implies intended portability to 'weird' distributions like CoreOS or Alpine Linux. They write it for, at least, Linux or more likely, the de-facto subset of POSIX that includes at least Linux, macOS, and Windows MinGW. To be clear, it doesn't really matter what Ubuntu's user-facing API is, because nobody writes a software package for Ubuntu specifically. > I think for a long time Python was just as much part of Ubuntu's intended user facing API as those two or GNU ls. (And major third-party applications do already do the right thing, in not making any assumptions of existence, but rather installing their own vendored versions of the runtimes that they can upgrade as needed.) The version OSes ship should be assumed to not exist. Which is important, because it means that developers can write to a stable target of 'POSIX compatible', assuming the existence of (and particular stable semantics of) particular standard runtimes.īut none of the 'modern' language runtimes are part of any such standard. part of some standard like POSIX, that an OS can be tested for conformance against. (Mind you, if you're a system software developer, whose software gets packaged into Operating Systems, then you do have to rely on this 'implementation detail.' Which often means targeting very old versions of runtimes and libraries, compared to the versions that application developers get to target.)Īlso, of course, there are 'standard' language runtimes that should be part of the userland - e.g.

These runtimes are actually something more like an 'implementation detail' of the OS - the kind of thing whose binaries should live in $PREFIX/libexec rather than $PREFIX/bin. They shouldn't be considered 'part of' the userland as this invites userland applications to rely on them. Whether you're using Linux, macOS, or BSD, OS-packaged language runtimes exist for the OS itself to use, in OS-internal scripts and underpinning OS services. Or at least, they shouldn't be putting it in the $PATH.

Completely remove python 2.7 mac