Self-contained highly-portable Python distributions
gregoryszorc.com
Self-contained highly-portable Python distributions
1–10 of 45 posts
Re: Self-contained highly-portable Python distributions
#21: 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."
Re: Self-contained highly-portable Python distributions
#3https://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.
Re: Self-contained highly-portable Python distributions
#4> 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. 1: https://github.com/indygreg/PyOxidizer/ From that readme, it seems PyOxy has a few related us…
Re: Self-contained highly-portable Python distributions
#5> 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. 1: https://github.com/indygreg/PyOxidizer/ From that readme, it seems PyOxy has a few related us…
Re: Self-contained highly-portable Python distributions
#6Most 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
Re: Self-contained highly-portable Python distributions
#7* 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.
Re: Self-contained highly-portable Python distributions
#8There 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." * Python Source: https://github.com/jart/cosmopolitan/tree/master/third_party... * Python Binary: https://cosmo.zip/pub/cosmos/bin/python w…
Re: Self-contained highly-portable Python distributions
#9A 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
Re: Self-contained highly-portable Python distributions
#10Did Astral's package cache proxy or another part cause the OpenAI/Huggingface incident?