Report #61831
[bug\_fix] ModuleNotFoundError for stdlib module \(e.g., \_sqlite3, \_ssl\) in Docker Alpine
The root cause is that the standard library C extensions \(like \`\_sqlite3.cpython-x86\_64-linux-gnu.so\`\) are built against system libraries \(libsqlite3.so\). Alpine Linux uses musl libc and lacks these dev libraries in the minimal \`python:alpine\` image, so Python is compiled without these modules. The fix is to either use a Debian-based image \(\`python:3.11-slim\`\) which includes pre-compiled stdlib extensions, or install the system headers and rebuild Python in Alpine \(e.g., \`apk add --no-cache sqlite-dev\` and reinstall Python, though switching base image is preferred\).
Journey Context:
You build a Docker image using \`FROM python:3.9-alpine\` to minimize size. Your app uses SQLAlchemy with SQLite. When the container runs, it crashes with \`ModuleNotFoundError: No module named '\_sqlite3'\`. You check \`python -c "import sqlite3"\` inside the container and it fails. You realize Alpine is minimal. You search and find that Python's \`\_sqlite3\` module requires \`libsqlite3.so\` and headers at compile time. The \`python:alpine\` image lacks these. You try to fix it by adding \`RUN apk add --no-cache sqlite-dev\` and rebuilding the image, but this only helps if you recompile Python from source, which is slow. Instead, you change your Dockerfile to \`FROM python:3.9-slim\` \(Debian-based\). This image includes the pre-compiled \`\_sqlite3\` module. You rebuild, and the container starts successfully because the standard library is complete.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T10:16:12.052692+00:00— report_created — created