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
Did Astral's package cache proxy or another part cause the OpenAI/Huggingface incident?
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.
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.
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
1: 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."
* 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.
That's what Cosmopolitan/APE does though, and they deliver a python:
* Source: https://github.com/jart/cosmopolitan/
* Python Binary: https://cosmo.zip/pub/cosmos/bin/python which is ~ 40MB.
- Project Status Update: https://github.com/indygreg/PyOxidizer/discussions/740
- https://gregoryszorc.com/blog/2024/03/17/my-shifting-open-so...
on the other hand a static cross platform single binary Postgres binary doesn't really have any performance hit.
(anecdotally, Personally I would be interested for something like this existing and maybe even integrating it with golang embed. Some of my apps are full stack golang with sqlite backend all baked into a single static binary which I can run and be cross-compiled but I would like to have the same level of flexibility but with postgres as well hopefully)
Why does the perf hit matter to you? Are you trying to run WASM binaries of PG in production? That seems like a terrible idea.
This project produces self-contained, highly-portable Python distributions. These Python distributions contain a fully-usable, full-featured Python installation: most extension modules from the Python standard library are present and their library dependencies are either distributed with the distribution or are statically linked.
The Python distributions are built in a manner to minimize run-time dependencies. This includes limiting the CPU instructions that can be used and limiting the set of shared libraries required at run-time. The goal is for the produced distribution to work on any system for the targeted architecture.
Some distributions ship with their build artifacts (object files, libraries, etc) along with rich metadata describing the distribution and how it was assembled. The build artifacts can be recombined by downstream repackagers to derive a custom Python distribution, possibly without certain features like SQLite and OpenSSL. This is useful for embedding Python in a larger binary. See the PyOxidizer sister project for such a downstream repackager.
Many users of these distributions might be better served by the PyOxy sister project. 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.
Contents: