python-build-standalone

python-build-standalone produces CPython distributions that carry their own dependencies and run wherever the target architecture runs. Extract the archive anywhere, execute the interpreter, and you get a full-featured Python with most of the standard library's extension modules present — their C library dependencies are either shipped alongside or statically linked in. This is the machinery behind "download a Python" as an operation that does not involve a system package manager, a compiler, or a configure script.

What "portable" means here

The builds are constrained in two directions at once. They limit which CPU instructions the compiler may emit, so a distribution built on a newer machine does not fault on an older one of the same architecture. And they limit the set of shared libraries required at run time, so there is no dependency on the host having a particular OpenSSL, libffi, or ncurses. The stated goal is that a distribution works on any system for the targeted architecture, which is a stronger claim than "works on the distro it was built for."

Some distributions ship more than the installed tree: the object files and libraries from the build, plus metadata describing how the distribution was assembled. A downstream repackager can recombine those artifacts into a custom Python — dropping SQLite or OpenSSL, for instance — which is what you want when embedding an interpreter inside a larger binary rather than installing one. Gregory Szorc's PyOxidizer is the sister project that does this, and PyOxy takes the same distributions and wraps them in Rust to produce a single-file executable interpreter.

Two archive flavors are published. The full archive carries the build artifacts and metadata described above. The install-only archive is just the usable installation, which is what you want if you only intend to run Python.

Quirks worth knowing before you ship it

The docs devote a whole chapter to behavior that differs from a system Python, and it is the part to read before adopting: special keys not working in the REPL, no tix on UNIX, no pip.exe on Windows, extra steps when linking the static library on macOS, libedit instead of readline on Linux, and references to build-time paths surviving into the installed tree. The last one is the usual source of surprise, since a relocated distribution can still contain strings pointing at wherever the build happened. There is also a project status page tracking per-target notes and the CPython tests that fail or get skipped on each target, which is the honest version of "does this actually work everywhere."

Who maintains it

The repository lives under the astral-sh organization — the same org as uv and Ruff — while the documentation is still served from gregoryszorc.com and still describes PyOxidizer and PyOxy as sister projects, with no mention of Astral anywhere. So the docs are the pre-handoff version; the org on the repo is the current fact. Practically, uv is why most people have one of these distributions on disk without having chosen it: uv python install fetches python-build-standalone archives rather than building CPython. That puts this project inside the supply chain described in open-source-security-astral, where Astral's release controls (Trusted Publishing, Sigstore attestations, immutable releases) are what stand between a compromised CI and every interpreter uv hands out. loopwerk-uv-ux-mess covers the other side of that relationship, where uv's package-management ergonomics lag its distribution and install story.

The relocatable-interpreter problem is the Python-shaped version of a question if-ai-writes-your-code-why-use-python raises from the other end: a compiled language hands you a single binary for free, and Python needs a project like this one to approximate it.

github.com/astral-sh/python-build-standalone — 4.3k stars, MPL-2.0. Documentation at gregoryszorc.com/docs/python-build-standalone.