PEP 656: Platform Tag for Linux Distributions Using Musl

It’s ok to limit the scope of your PEP to common cases and not support dynamically linked interpreters or mixed builds with glibc. You could include something like

This PEP only applies to Python interpreters which dynamically linked to musl shared library. Statically linked interpreters or mixed builds with glibc are out of scope and not supported by musllinux platform tags.

1 Like

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.

2 Likes

Do those binaries work with Linux Kernel 2.2 from 1999? :sweat_smile:

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?

2 Likes

I’ve added a paragraph to limit the scope to dynamically linked Python interpreters running on musl libc.

2 Likes

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

1 Like

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

1 Like

Discussion seems to have quieted down. Are there further issues I need to address?

2 Likes

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

1 Like

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!

2 Likes

musllinux support in packaging is ready for review: PEP 656 musllinux support by uranusjr · Pull Request #411 · pypa/packaging · GitHub

2 Likes

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.

1 Like

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.

1 Like

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.

10 Likes

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

3 Likes

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.

2 Likes

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.

1 Like

I started implementing support for musllinux in auditwheel and ran into an issue. See my original comment on the issue tracker:

I posted a question about this on the #musl channel as well.

1 Like

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.

1 Like

Auditwheel 5.0.0 is now published on PyPI with PEP 656 support.
musllinux_1_1 images are available on Quay thanks to Add image for musllinux_1_1 by lkollar · Pull Request #1135 · pypa/manylinux · GitHub
cibuildwheel support is also on its way: feat: add musllinux support (PEP 656) by mayeut · Pull Request #768 · pypa/cibuildwheel · GitHub

This should allow packagers to get started & report issues if need be.

3 Likes

Happy to report that as soon as preparations for musllinux by Liath · Pull Request #9982 · pypa/warehouse · GitHub lands on the warehouse side we’ll be ready to upload musllinux wheels for pyca/cryptography.

5 Likes