3 ms·

Linux isn’t one target, but a matrix of targets: providing binaries for Linux means picking architectures, libc versions and variants, OpenSSL versions and fork

Linux isn’t one target, but a matrix of targets: providing binaries for Linux means picking architectures, libc versions and variants, OpenSSL versions and forks, etc. against which to canonicalize. This also has downstream implications, e.g. a CPython binary with a static build of OpenSSL might contain an OpenSSL vulnerability that CPython is now on the hook for remediating (rather than delegating that remediation responsibility to downstream distributions). Some of this complexity is also true for Windows, but Linux’s (good!) diversity makes it a bigger challenge.

the__alchemist 2y ago
Valid, but you can make three binaries that will work for the most common use cases. (I've done this) For a project as big as this, doing so is trivial, vice offloading it onto the users.
- nine_k 2y ago
  > offloading it onto the users Not end users but distro maintainers. If you run almost any Linux distro imaginable, it has Python already in the distro. If you want to try a version that's not yet even supported by the unstable branch of your distro, or not available on some PPA, etc, you need to be well enough versed in its dependencies to build it yourself. Alpha-quality software, of course, benefits from more eyes, but it mostly needs certain kinds of eyes.
- Joeboy 2y ago
  I haven't really used it in anger, but I believe `uv` can install pre-compiled python binaries (from... somewhere?). Maybe also pyenv?
  - scottyeager 2y ago
    With pyenv it's built from source. That's pretty seamless if you have the build dependencies installed. With rye and uv you get the prebuilt portable versions from indygreg. Those have some significant deviations from what you get with a system package or pyenv built version, so there can be some caveats.
amelius 2y ago
Why libc can't converge to a long-term stable version is another mystery.
- woodruffw 2y ago
  What do you mean? Glibc is well known for its commitment to compatibility. But that isn’t the issue: the issues are that there’s more than one libc, and that consumers actually want incompatible changes sometimes.
  - vilunov 2y ago
    That's not usually the issue. Glibc is used by 90% of main distros, notable exception is alpine used in docker images. The problem is Linux ecosystem's fixation on "build environment = runtime environment" idea, making it incredibly difficult to build against older versions of glibc (e.g. Ubuntu 22.04) if you're using something new such as latest Arch. This is not a problem on macOS, you can use an SDK for a particular OS version on any other recent version.

the__alchemist 2y ago

Valid, but you can make three binaries that will work for the most common use cases. (I've done this) For a project as big as this, doing so is trivial, vice offloading it onto the users.

nine_k 2y ago
> offloading it onto the users Not end users but distro maintainers. If you run almost any Linux distro imaginable, it has Python already in the distro. If you want to try a version that's not yet even supported by the unstable branch of your distro, or not available on some PPA, etc, you need to be well enough versed in its dependencies to build it yourself. Alpha-quality software, of course, benefits from more eyes, but it mostly needs certain kinds of eyes.
Joeboy 2y ago
I haven't really used it in anger, but I believe `uv` can install pre-compiled python binaries (from... somewhere?). Maybe also pyenv?
- scottyeager 2y ago
  With pyenv it's built from source. That's pretty seamless if you have the build dependencies installed. With rye and uv you get the prebuilt portable versions from indygreg. Those have some significant deviations from what you get with a system package or pyenv built version, so there can be some caveats.

amelius 2y ago

Why libc can't converge to a long-term stable version is another mystery.

woodruffw 2y ago
What do you mean? Glibc is well known for its commitment to compatibility. But that isn’t the issue: the issues are that there’s more than one libc, and that consumers actually want incompatible changes sometimes.
- vilunov 2y ago
  That's not usually the issue. Glibc is used by 90% of main distros, notable exception is alpine used in docker images. The problem is Linux ecosystem's fixation on "build environment = runtime environment" idea, making it incredibly difficult to build against older versions of glibc (e.g. Ubuntu 22.04) if you're using something new such as latest Arch. This is not a problem on macOS, you can use an SDK for a particular OS version on any other recent version.