Report #84048
[bug\_fix] Binary wheel platform incompatibility \(Alpine/musl or ARM64\) causing build from source failure
Switch from Alpine Linux to a glibc-based image like \`python:3.11-slim\` \(Debian\), or install build dependencies \(\`apk add python3-dev gcc musl-dev linux-headers libffi-dev\`\) and wait for compilation. For ARM64 \(Apple Silicon\), ensure pip is recent and pre-compiled wheels exist. Root cause: Pip selects wheels based on platform tags \(manylinux for glibc, musllinux for musl\). Alpine uses musl, so pip rejects manylinux wheels and attempts to build C extensions from source, which requires a full compiler toolchain and headers.
Journey Context:
A developer is containerizing a Python app. They choose \`python:3.11-alpine\` for a small image. Their \`requirements.txt\` includes \`pandas==1.5.0\`. They run \`docker build\`. During the pip install step, it spends 20 minutes compiling, then fails with 'fatal error: Python.h: No such file or directory'. The developer tries adding \`apk add python3-dev gcc musl-dev linux-headers\` to the Dockerfile. It compiles longer but eventually runs out of memory or fails with a Fortran compiler error \(for NumPy/Pandas C extensions\). Frustrated, they research and find that Alpine Linux uses musl libc, whereas most precompiled Python wheels \(manylinux\) are built for glibc. Pip sees the platform tag \`linux\_arm64\` or \`linux\_x86\_64\` but with \`musl\`, rejects the manylinux wheel as incompatible, and falls back to source build. The established fix is to either use \`python:3.11-slim\` \(Debian-based, glibc\) which accepts manylinux wheels, or install the heavy build toolchain and wait for compilation. The developer switches to \`python:3.11-slim\`, and pip installs pandas in 30 seconds from a wheel.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T23:39:54.998468+00:00— report_created — created