7/27/2026 at 8:18:32 PM
These are the Python distributions we use in uv (https://github.com/astral-sh/uv), i.e., when you install Python with uv, you're installing from python-build-standalone. (Same goes for many of the other tools that can install Python for you, like pipx, Hatch, Poetry, Bazel, etc.)Most of our engineering time on the project over the past ~year and a half has been split into three buckets:
1. Keeping up with upstream CPython. (We're also hoping to upstream as much of this work as we can into CPython itself.)
2. Fixing any / all of the known "quirks" vis-a-vis CPython.
3. Making these distributions as fast as (or faster than) any other CPython distribution.
If you're interested, I wrote a bit about the why / how here when we took over maintenance of the project: https://x.com/charliermarsh/status/1864050698574311561
by charliermarsh
7/27/2026 at 8:51:07 PM
At my employer, we'd been using a similar scheme to build and ship interpreters along with releases of various pieces of software for years. Although I was interested in p-b-s for some time, I was loathe to consider switching to it since one of the major motivations for building our own binaries was the collection of random obscure changes or customizations we'd accumulated in our build harness over the years, and the fact that we need to provide some guarantees about the provenance of the binaries.Despite those needs though, I eventually looked into the p-b-s builder and found that I couldn't make a serious argument against continuing to maintain our builder and all of the random crap that's needed to manage all the dependencies and using p-b-s. It solves all the same problems and after having switched to it a couple of years ago, my initial concerns about possibly needing to get changes upstreamed never became an issue as your folks pretty much always run into and fix stuff before I do and have been both really pragmatic and helpful in any of the discussions surrounding issues. I keep hoping for an opportunity to contribute something back since the project has really saved me a great deal of toil over the past year or two since adopting it.
I really like the model of treating the interpreter as just another runtime dependency, and after working in the Erlang universe for a few years I keep thinking there are some interesting opportunities for tooling related to bundling stripped-down versions of the runtime stuff along with an application rather than some of the more exotic approaches. Stuff like rebar/erlang.mk might be a nice pattern to study.
Anyhow if Indygreg is reading this, huge thanks and nice work, and I really appreciate all the work you (Charlie) and the astral folks have put in, it's been a real bright spot at work for a while.
by gooseyard
7/28/2026 at 1:12:41 AM
> When you download Python from http://python.org (on Linux or macOS), what you're actually downloading is an installer that builds Python from source on your machine.> The net effect is that on Linux and macOS, you can't "download a Python binary" from... anywhere. Other than the python-build-standalone project.
Are you sure this is right about macOS? I just had a look inside the macOS installer from python.org and there are definitely some binaries in there.
by ameliaquining
7/28/2026 at 3:10:22 AM
It's definitely wrong for macOS. The python.org macOS download has been an installer package that installs Python to /Applications as long as I can remember.(That said, I've rarely used it, preferring either the macOS/Xcode-provided Python or these self-contained Pythons which I use via uv.)
by js2
7/28/2026 at 4:19:11 AM
It’s incorrect for Linux too, distributions build Python binaries for their repos.by hack1312
7/28/2026 at 5:03:42 AM
The thread does mention that:> (The notable exception here is that Linux distros _can_ support, e.g., `apt install python3` and ship a binary, because IIUC they can rely on standardized system paths.)
Of course, there are lots of use cases where that doesn't suffice, such as, for example, if you care what Python version you're using.
by ameliaquining
7/28/2026 at 3:19:58 AM
i think that sentence is taken out of context a bit, the problem with those pkg binaries is that they're not portable—which the post describesEDIT: actually no, I think charlie is wrong on that point, he said the installers compile python but that only happens with python-build-based installers like pyenv. still, the fact those binaries lack portability is the real problem.
by jdxcode
7/28/2026 at 3:17:21 AM
mise uses these as well and adopting them has been a massive improvement in the user experience for my python users. y'all have been doing a fantastic job maintaining them.i'm also doing the same for ruby—maintaining the binaries myself which is becoming the default in mise next week: https://github.com/jdx/ruby
i'm a firm believer that pre-compiled, portable binaries are the best way to distribute runtimes and clis.
by jdxcode
7/28/2026 at 12:43:54 PM
The combo of mise + UV has made my development environment setup/recreation so seamless. We've come a long way.(Props to your work on mise)
by Calamity
7/27/2026 at 9:00:42 PM
I install these Python builds into distroless containers with uv python install and it just works. (If you try this with Google’s images, use gcr.io/distroless/cc, libgcc/libstdc++ is needed for some extensions, like numpy)by brewmarche
7/28/2026 at 2:39:44 AM
Pretty sure a similar approach should work using smolvms from smolmachines.comby chrisweekly