MUSL distributions lacking proper interpreter information

[ofek]

The following illustrates that for some reason the standalone distribution's pip does not consider MUSL wheels and will download the source distribution:

docker run --rm -d --name builder python:alpine sleep infinity
docker exec builder ash -c "apk update && apk add curl"
docker exec builder curl -LO https://github.com/indygreg/python-build-standalone/releases/download/20240415/cpython-3.12.3+20240415-x86_64_v3-unknown-linux-musl-install_only.tar.gz
docker exec builder tar xzf cpython-3.12.3+20240415-x86_64_v3-unknown-linux-musl-install_only.tar.gz
docker exec builder /python/bin/python -m pip install uv

I then got the idea to try installing with UV itself but that also doesn't work (but of course itself installs properly with the system Python): astral-sh/uv#3486

[charliermarsh]

I am interested in what packaging._get_musl_version is returning for the executable, and where it's failing.

[ofek]

$ docker exec builder /python/bin/python -m pip install -q packaging
$ docker exec builder /python/bin/python -c "from packaging._musllinux import _get_musl_version;print(_get_musl_version('/python/bin/python'))"
None

Based on its description, could it be because the distribution is statically compiled i.e. #86?

#218 (comment):

If PEP 656 had been around when I created this project, I may have just made musl libc dynamic by default.

[konstin]

I think this effectively a duplicate of #86, we need dynamically linked musl builds for python-build-standalone to be usable on alpine.

[ofek]

I know it was from before your time but do you know why the original decision opted for static? I don't quite understand the benefit.

[charliermarsh]

I believe it was a requirement for PyOxidizer which was the motivating force behind the project in the first place (I may be wrong) -- it's similar to #221.

[konstin]

See astral-sh/uv#2382 for a (currently failing) test on the uv side

[zanieb]

Fixed in #541