Hacker News Reader

Comment by woodruffw | Hacker News Reader

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.

View on HN

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.

> 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.

I haven't really used it in anger, but I believe `uv` can install pre-compiled python binaries (from... somewhere?). Maybe also pyenv?

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.

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

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.

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.

Reply on news.ycombinator.com