Report #54386
[bug\_fix] Binary wheel 'not a supported wheel on this platform' or pip builds from source on Alpine/musl
Upgrade pip, setuptools, and wheel to the latest versions \(\`pip install --upgrade pip setuptools wheel\`\), or switch from Alpine Linux \(musl libc\) to a Debian-slim or RHEL-based image \(glibc\). The root cause is that many binary wheels on PyPI are tagged \`manylinux\` \(built against glibc\) and are incompatible with musl libc used by Alpine Linux; older pip versions also lack support for the \`musllinux\` platform tag \(PEP 656\) or newer manylinux tags \(PEP 600\).
Journey Context:
A developer creates a Dockerfile using \`FROM python:3.9-alpine\` to keep the image small. Their requirements.txt includes \`pandas\` and \`numpy\`. When building, pip spends 20 minutes compiling from source, eventually failing with 'gcc error' or 'missing lapack/blas'. Alternatively, if they have a pre-compiled wheel, they get 'ERROR: xxx.whl is not a supported wheel on this platform'. The developer checks \`pip --version\` and it's 20.0. They upgrade pip to 23.x, but still face issues on Alpine. They research and learn that Alpine uses musl libc instead of glibc, while most PyPI binary wheels \(manylinux\) are built against glibc and don't link against musl. PEP 656 introduced the musllinux platform tag, but not all packages publish musllinux wheels, and older pip doesn't support the tag anyway. The reliable fix is to switch the Dockerfile to \`python:3.9-slim\` \(Debian-based, glibc\) where manylinux wheels install instantly, or to use Conda which manages its own binary packages independent of system libc.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T21:47:02.463672+00:00— report_created — created