Alpine 3.14 Python cannot read musllinux wheels
Hi, I've been involved with the musllinux wheel rollout for Python. This was a major project, starting with a PEP 656, which was accepted on the condition that "that the [musllinux] community would work together to ensure things worked". This was followed by changes to PyPI, pip, auditwheel, manylinux, and cibuildwheel. All the pieces have been finished, and musllinux wheel have been rolling out on PyPI. I have been trying to convince maintainers that supporting musllinux wheels is worthwhile.
And then someone noticed that the structure of a musllinux wheel looks like this:
psycopg_binary-3.0.4-cp39-cp39-musllinux_1_1_x86_64.whl
- _psycopg.cpython-39-x86_64-linux-gnu.so
And, thinking the -gnu
suffix was ugly, patched CPython to only produce and read -musl
instead. This change has not been accepted into CPython 3.11, and is very, very unlikely to be backported to older versions of CPython, since it would break all existing wheels, for almost no benefit at all. (The only benefit would be installing wheels to a shared directory that both musl and glibc distributions can access - the is a "new feature" that can be requested of Python 3.11, but is not a feature currently supported.)
This unaccepted-in-upstream patch was applied to Python in Alpine 3.14. Now Alpine in 3.14 cannot pip install any musllinux wheels that worked (and still work) with Alpine 3.12-3.13, as well as the python:3.9-alpine
and python:3.10-alpine
docker images.
This patch (https://git.alpinelinux.org/aports/tree/main/python3/bpo-43112.patch?h=3.14-stable) needs to be reverted until there's resolution upstream. CC @ncopa.
- https://github.com/pypa/pip/issues/10678
- https://discuss.python.org/t/a-mess-with-soabi-tags-on-musllinux/11688
- https://github.com/pypa/cibuildwheel/issues/934
- https://github.com/pypa/auditwheel/issues/349
- https://github.com/pypa/manylinux/pull/1225
- https://bugs.python.org/issue43112
- https://github.com/python/cpython/pull/24502
- https://github.com/nedbat/coveragepy/issues/1268#issuecomment-956639366