However, it might be reasonable to require installers to not claim compatibility with the musllinux tags if they statically link the library. I don’t think there’s any precedent on this - I know of no other system where static linking the C library is common.
Do those binaries work with Linux Kernel 2.2 from 1999?
Sorry, I couldn’t resist. I’m just wondering, what’s minimum Kernel ABI for a static binary? For example does MUSL still support
SYS_socketcall multiplex dispatching on X86 ABI?
I’ve added a paragraph to limit the scope to dynamically linked Python interpreters running on musl libc.
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).
Discussion seems to have quieted down. Are there further issues I need to address?
My only comment is that the passage
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!
musllinux support in
packaging is ready for review: PEP 656 musllinux support by uranusjr · Pull Request #411 · pypa/packaging · GitHub
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
I’ll try to take a look in the next few days. If I’ve not responded by the end of the week, please ping me again.
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.
Thanks Paul! I’ve submitted a PR to change to status: PEP 656: Accepted by uranusjr · Pull Request #1928 · python/peps · GitHub
(Edit: The PR was merged before I can finish this post. Wow that’s quick.)
The implementation for musllinux identification in
packaging is also close to ready, so it even has a chance to be included in pip 21.1 (due this month).
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_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.