TL;DR: On 2024-12-17, we'll be taking stewardship of python-build-standalone, Gregory Szorc's foundational project for building and installing portable Python distributions. You can read Gregory's own announcement here.

python-build-standalone powers Python installation for uv, Rye, mise, Bazel's rules_python, pipx, Hatch, and more, with over 70,000,000 downloads since its release.

For much of the ecosystem, it's now the primary source of Python installations.

But given Gregory's shifting open source priorities, he's been looking for help. And since March, we've been working with him to maintain python-build-standalone. We've shepherded every release since April, automated the release process itself, built out support for Python 3.13 (including support for free-threaded Python), and more.

To quote Gregory's own announcement, python-build-standalone "is effectively an Astral maintained project and has been that way for months." So, to reflect that evolution, on 2024-12-17, Gregory will be transferring the project to the Astral organization, where we'll continue to maintain and push the project forward.

We use python-build-standalone in uv, but it's also part of a broader ecosystem and will continue to be developed with that broader ecosystem in mind. We're excited to devote full-time resources to its maintenance and development, and to foster the level of engagement and activity that you might be familiar with from Ruff or uv.

What's a "standalone" Python distribution?

Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary. This is fine if you're building and installing Python on a single machine, but it's a problem if you want to pre-build Python and then distribute it to other machines. CPython is also dynamically linked against a number of system libraries, which can cause trouble if the target machine doesn't have those libraries installed. In this way, CPython is not "standalone": it's tightly coupled to the system on which it was built.

So, for example, when you download Python on Linux (e.g., from python.org), what you're actually downloading is the CPython source, which is then built on your machine. Similarly, when you install Python with pyenv, it too is building from source.

While source installations have their benefits, they have some drawbacks too:

  1. Building from source is much slower than downloading a pre-built binary. This is especially true if you're building CPython with optimizations enabled (i.e., PGO and LTO). Notably, pyenv does not build with optimizations enabled by default, so if you're using pyenv to install Python, you're leaving significant performance improvements on the table.
  2. Building from source introduces a dependency on a build toolchain (e.g., gcc). And it can fail! For a variety of reasons: missing dependencies, incompatible system libraries, etc.

The net effect, though, is that you can't "download a Python binary" from... anywhere. Other than the python-build-standalone project.

Specifically, python-build-standalone solves these problems by (1) statically linking Python against its dependencies; and (2) patching the CPython build system to operate on relative, rather than absolute paths.

With those modifications, it then builds Python from source across a wide matrix of Python versions, platforms, and build variants (e.g., optimized vs. debug builds), and publishes the built distributions to GitHub Releases.

The Python builds produced by python-build-standalone are truly standalone: you can download, unzip, and run them on any machine, without any additional dependencies. They make uv python install feel magical. Not only is it extremely fast, but (to borrow from Armin), it's hassle-free.

The future of standalone Python distributions

I first met Gregory about two years ago, when I had just started working on Ruff, and we catch up from time to time given our shared interests in Rust and Python.

Earlier this year, Gregory mentioned to me that he was looking for help maintaining python-build-standalone. Given our use of the project in uv, and the load-bearing role it plays in the Python ecosystem, we were eager to help out.

Since March, we've been working with Gregory to maintain the project, ship improvements, and manage releases, keeping the project up-to-date with the latest Python patch and minor versions, upgrading dependencies (e.g., OpenSSL) in response to security advisories, and more.

We're now at a point where we feel comfortable stewarding the project going forward. By moving the project into the Astral organization, we're committing to its long-term maintenance and development.

In particular, we have (at least) four goals in mind:

  1. Keep the project up-to-date with Python releases. Every year, a new Python minor release comes out; and every year, the Python build system changes. We want to ensure that python-build-standalone keeps pace with those changes, providing the latest Python versions as soon as they've hit a stable release, be they patch releases or new minor versions.
  2. Upstream changes to the CPython build system. Many of the patches that python-build-standalone applies to the CPython build system are general-purpose improvements that would benefit the broader Python ecosystem. We want to work with the Python core developers to upstream those changes, to reduce the delta between the official CPython build system and that of python-build-standalone.
  3. Remove some of the project's existing limitations. For example, while python-build-standalone ships musl-based Python builds, those builds are incompatible with Python extension modules, a significant limitation in practice.
  4. Improve the project's build and release process. python-build-standalone builds 947 artifacts on every commit, and for every release. That's a lot of builds! We want to invest in making the build and release process easy, efficient, and continuous. For example, it'd be sensible for us to build from CPython HEAD on a continuous basis, rather than on every CPython release. We can also expand the set of supported platforms by moving beyond GitHub's free runners. (For example, we could ship Python builds for ARM Windows.)

If this sounds interesting to you, we're hiring! And we're especially interested in folks with the kind of build engineering experience that would be relevant here.

Thanks, Gregory

Finally, I want to take a moment to thank Gregory for all the work that he's put into python-build-standalone — for onboarding us onto the project, and for entrusting Astral with its development going forward.

python-build-standalone was initially built to power PyOxidizer, but has since grown into a critical part of the Python ecosystem. The project itself is both a tremendous technical and social achievement, and Gregory's commitment and expertise are clear and obvious throughout the codebase and documentation.

I'm also grateful that Gregory will remain involved with the project as we build upon those foundations and continue investing in standalone Python distributions.