> Many users of these distributions might be better served by the PyOxy sister project [1]. PyOxy takes these Python distributions and adds some Rust code for enhancing the functionality of the Python interpreter. The official PyOxy release binaries are single file executables providing a full-featured Python interpreter.
From that readme, it seems PyOxy has a few related uses:
- It can produce a single file executable representing a Python app including the interpreter
- It can ship self-contained Python interpreters and related to be embedded or used as a library in a larger application
- PyOxidizer can serve as a bridge between Rust and Python - "PyOxidizer can be used to easily add a Python interpreter to any Rust project. But the opposite is also true: PyOxidizer can also be used to add Rust to Python."
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.
There is also the APE/Cosmopolitan cross platform binaries, which includes a python. Yes, cross platform binaries. The binaries run "natively on Linux + Mac + Windows + FreeBSD + OpenBSD 7.3 + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable."
The important distinction is that self-contained doesn’t mean one binary that runs everywhere...does it?
A virtualenv still depends on the host interpreter and OS.
These distributions pin the interpreter, standard library, and most runtime dependencies, but the remaining boundary is where production surprises happen:
- glibc version, CPU feature level, and third-party native extensions.
The musl builds remove libc dependencies, for example, but can’t load ordinary `.so` extensions.
I understand why it's important for uv to maintain this as it provides a reproducible Python base while making the platform-specific extension layer an explicit part of the deployment decision
it's a sort of inside joke about google cloud cli being > 1gb , because they include a python distribution and a bunch of third party deps . so i'm glad to hear that this app can ship smaller packages
I keep meaning to explore compiling Python +libs to WASM for running in a desktop environment. It is already Python, so I am willing to accommodate enormous performance losses. I just want to package up the code into something more straightforward than PyInstaller.
Every time I look into scripting in programs like Kicad, Freecad or Inkscape, I run into Python compatibility problems. I can usually fix it, but what a mess. Package management in 2026 leaves a lot to be desired.
> library dependencies are either distributed with the distribution or are statically linked.
I have messed up my packages multiple times and have feared installing anything due to it.
I always prefer this type of distributions for any software and now, it works like a charm.
17 comments
[ 0.16 ms ] story [ 1010 ms ] thread1: https://github.com/indygreg/PyOxidizer/
From that readme, it seems PyOxy has a few related uses:
- It can produce a single file executable representing a Python app including the interpreter
- It can ship self-contained Python interpreters and related to be embedded or used as a library in a larger application
- PyOxidizer can serve as a bridge between Rust and Python - "PyOxidizer can be used to easily add a Python interpreter to any Rust project. But the opposite is also true: PyOxidizer can also be used to add Rust to Python."
https://github.com/astral-sh/python-build-standalone
If you're looking to bundle Python into another application - a macOS desktop app for example - these are exactly what you need.
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
* Python Source: https://github.com/jart/cosmopolitan/tree/master/third_party...
* Python Binary: https://cosmo.zip/pub/cosmos/bin/python which is ~ 40MB.
Apparently you can zip your .py files in with the python binary and make it run, but I haven't had a chance to try and play with that yet.
A virtualenv still depends on the host interpreter and OS. These distributions pin the interpreter, standard library, and most runtime dependencies, but the remaining boundary is where production surprises happen:
- glibc version, CPU feature level, and third-party native extensions.
The musl builds remove libc dependencies, for example, but can’t load ordinary `.so` extensions.
I understand why it's important for uv to maintain this as it provides a reproducible Python base while making the platform-specific extension layer an explicit part of the deployment decision
Did Astral's package cache proxy or another part cause the OpenAI/Huggingface incident?
I have messed up my packages multiple times and have feared installing anything due to it. I always prefer this type of distributions for any software and now, it works like a charm.