This is somewhat off topic, but there is of course a limit to how old of a Linux a statically linked binary will run on musl libc - Supported Platforms says Linux kernel >= 2.6.39 with undefined support for older. And when we talk about machines that are that old, we need to talk about instruction set compatibility (e.g. no SSE/AVX).
To move this discussion forward, maybe the platform tag should somehow denote Linux ABI compatibility like the existing manylinux tags do? I’m skeptical we’ll ever need to version it given backwards compatibility commitment from musl and Linux on the interfaces used. But the long arc of time has a way of invalidating assumptions.
IMO this is one of the things that fall into the “play well with others” rule introduced by PEP 600. Wheels can only make use of newer kernel features when the version is generally shipped by default by all popular musl-based distros, and once all major musl-based distros ship a certain kernel version by default, users that rely on older kernel versions are automatically removed from the coverage of a musllinux tag.
I am honestly not familiar with how popular musl-based distros handle their kernel version support, nor know how the “play well” rule is going to work out (since AFAIK no projects are currently distributing PEP 600 wheels yet). But I feel it’s probably better for the community as a whole if both glibc and musl distros can use this same rule so the experience learnt by either can advance things for both sides (and other libc implementations if they need their own platform tag one day).
Logic behind the new platform tag largely follows PEP 600, and require wheels using this tag make similar promises. Please refer to the PEP for more details on rationale and reasoning behind the design.
could be read as if PEP 656 provides more details, when I think you mean PEP 600 does. I would say “Please refer to that PEP” to be explicit.
Also, I think “and require wheels using this tag” should be “and requires wheels using this tag”.
I have submitted a change to explain more about the perennial design (a rewrite of this comment above). The new paragraph is a reiteration to things already covered by PEP 600, but reading this thread again, many comments seem to still want to add ideas from previous manylinux specs intentionally not covered by PEP 600 (and therefore this PEP), so I figured it’s best to repeat the rules again in PEP 656.
The PR also contains the wording clarification and typo fix suggested by the immediately above comment. Thanks!
Another week has passed without further comments, and ~1month from the last meaningful update. With the intention to move things forward, may I ask for pronouncement from the BDFL-Delegate @pfmoore?
The implementation for installation-time tag compatibility detection has been proposed to packaging (linked in the comment immediately above), and I plan to move onto the wheel generation part. The first thing I’ll do is to open an issue auditwheel to discuss whether it’s a good fit for this, and decide whether to expand auditwheel or develop an entirely standalone tool. Either way, cibuildwheel will then be able to use a command to “repair” (using auditwheel terminology) a wheel into musllinux compatible.
It is with pleasure that I formally accept PEP 656. Congratulations @uranusjr and thanks for moving this through to a successful conclusion.
As with perennial manylinus, I don’t claim to be an expert in the technical details of MUSL, so I’m taking the view that the technical experts in the community have had the opportunity to flag any concerns or issues, and the lack of any such feedback indicates that we have consensus that the proposal is technically sound.
The approach of requiring wheels claiming musllinux compatibility to work on all “mainstream” distributions, and to “play nice with others” matches the approach in PEP 600, and I expect it to work as well here as it did in that case. But I would advise people working on the specification to take a cautious view over what gets admitted as “available everywhere”, and in particular to focus on distributions used in containers as the “lowest common denominator”, as containers are the driving motivation for this specification.
One concern I have with the specification is that the necessity for wheels to bundle “private” copies of any libraries they use may result in an increased size for images relying on many pre-built musllinux wheels, as opposed to custom-built binaries that share libraries. This may be an issue for containers (where overall size is important) and I encourage the people working on the practical aspects of the musllinux toolchain to monitor the impact of this.
This leaves the last missing piece to actually produce and validate those wheels. I have a mind in looking into this, but please do feel free to do it if you know what to do. I haven’t even figured that out yet, and don’t really have much time to move things forward recently.
100% spot on, this is also my biggest concern going forward. My hope is there’s going to be some kind of community with people coming from different Linux distributions (Alpine obviously, Arch has a lot of users as well), but from what I can tell there doesn’t seem to be a lot of communication going on—most of the time I hear about them is people complaining something doesn’t work to the general Python users community, and those people don’t seem to talk to each other at all. I would be very interested in seeing some sort of user circles happening (although probably not in the position to start one myself).
There’s a talk at the language summit about packaging Python for Linux: PyCon 2021 - Python Language Summit 2021. I have tried to get the Linux distros into a common spot, but so far been unsuccessful in convincing them to follow through on the suggestion.
I’d really like a better reference than a short email on the backwards compatibility issue.
Binary ABI compatibility is way outside my territory so I don’t know if/how relevant this is but I just found a musl ABI tracker which indicates when symbols have been added/modifed/removed.
According to it, the only time symbols have disappeared in the last 10 years was when 1.0.1 dropped __syscall(), __syscall_cp() and __syscall_ret() (anyone heard of those?). Looking at the backwards compatibility warnings, they all appear to be irrelevant or false positives; mostly function argument renames (which doesn’t touch ABI) or occasionally a function will go from returning void to a real return value.
So that does appear to back up the claim in the email - that symbol backwards compatibility is guaranteed but the exact behaviour of those symbols is not.
I think this is the bottom line. Given Alpine is the overwhelming musl use case, and almost all usage of it is from containers, I feel it is reasonable to expect most musl wheels to be built from containers. Personally I think we can tag the wheel to whatever run-time musl version in the build environment, and maybe offer a flag to explicit override that if needed. I also expect most musl users to live pretty close to the edge of things anyway (running CPython on musl is an adventure in itself!) so the problem of over-conservative tagging is likely minimal in practice.
musl libc - Supported Platforms says Linux kernel >= 2.6.39 with undefined support for older. And when we talk about machines that are that old, we need to talk about instruction set compatibility (e.g. no SSE/AVX).
