Announcing the PyOxy Python Runner, a single file (C)Python distribution(gregoryszorc.com)
gregoryszorc.com
Announcing the PyOxy Python Runner, a single file (C)Python distribution
https://gregoryszorc.com/blog/2022/05/10/announcing-the-pyoxy-python-runner/
5 comments
I'm trying to figure out the same... well, at least a related question. What's the point of this? Why would I want a single-file version of Python?
Is the main idea here to be able to provide some of the benefits of a static binary (like a Go compiled binary)? Namely, you can keep this pyoxy binary with your project and then all of your custom code/dependencies/etc... are kept together in one single folder without relying on the system Python?
If so... I like it. Then the next step would be merging this binary with your code (plus dependencies) in one file, or maybe pyoxy plus an egg file? (or wheel? I can't keep track anymore). Seems like it would work for pure python dependencies pretty well, but would still have issues with dependencies that require compiling?
Is the main idea here to be able to provide some of the benefits of a static binary (like a Go compiled binary)? Namely, you can keep this pyoxy binary with your project and then all of your custom code/dependencies/etc... are kept together in one single folder without relying on the system Python?
If so... I like it. Then the next step would be merging this binary with your code (plus dependencies) in one file, or maybe pyoxy plus an egg file? (or wheel? I can't keep track anymore). Seems like it would work for pure python dependencies pretty well, but would still have issues with dependencies that require compiling?
>What's the point of this? Why would I want a single-file version of Python?
If I want to deploy a Python program on a Windows machine, my current workflow is roughly:
PyInstaller, Nukita, etc probably already make this possible, but I have never taken the plunge to explore them. I have assumed there are some rough edge gotchas (C libraries) that would make me regret the decision.
If I want to deploy a Python program on a Windows machine, my current workflow is roughly:
- Install Python system wide
- Ensure there is Python venv + pip + (QoL) virtualenvwrapper
- Create virtual environment per program
- Load up my code
PyInstaller, Nukita, etc probably already make this possible, but I have never taken the plunge to explore them. I have assumed there are some rough edge gotchas (C libraries) that would make me regret the decision.
PyOxy could be a great complement to `shiv` (generates zipapps like you described). Shiv had system-installed python as a requirement, so this makes it fully portable.
https://shiv.readthedocs.io/en/latest/
EDIT: oh I just read through the PyOxidizer docs, seems like they already do have this capability as a goal, PyOxy is actually extracting out the shippable one-exec python out.
https://shiv.readthedocs.io/en/latest/
EDIT: oh I just read through the PyOxidizer docs, seems like they already do have this capability as a goal, PyOxy is actually extracting out the shippable one-exec python out.
Okay, so more for end-user facing applications? That makes a lot more sense. I still have server installed applications in my head, where getting the “right” Python installed can be solved by multiple mechanisms. For end-user applications, having a Python binary that travels with the program code makes a ton of sense. Thanks!
You should also check out cx_Freeze, I have had better luck with it than PyInstaller with my project(s).
FWIW, if your PyInstaller experience is from several years ago, I'd strongly recommend checking it out again. I used to dread its updates because they usually broke something, but everything has been super smooth in the last 1-2 years. :)
Recent, actually. I got PyInstaller working but I tried cx_Freeze because it had an easier route to generating a quick .msi. I found cx_Freeze easier to use and ended up porting over to it, but to each their own.
Yes, the idea is a more efficient version of a Python zipapp https://realpython.com/python-zipapp/
It's called Python Packed Resources https://pyoxidizer.readthedocs.io/en/stable/oxidized_importe...
Looks like a very slick set of tools.
It's called Python Packed Resources https://pyoxidizer.readthedocs.io/en/stable/oxidized_importe...
Looks like a very slick set of tools.
Cool!
It might be nice if easy-to-use distributions like conda adopt this and give us a 1GB all-in-one-binary to run whatever I want. A large binary is fine as long as it is mmap-ed and doesn't waste memory.
It might be nice if easy-to-use distributions like conda adopt this and give us a 1GB all-in-one-binary to run whatever I want. A large binary is fine as long as it is mmap-ed and doesn't waste memory.
Check out micromamba, it's a single binary conda environment manager with no dependencies (not even on python itself): https://mamba.readthedocs.io/en/latest/user_guide/micromamba... It's great in my experience.
You can do better than that for single-file distributions. You ought to be able to cram the python-packed-resources blob and the yaml file into .data sections of a pyoxy executable. I did something similar with ruby 1.8, years ago.
Technically possible, but I don't think that works with code signing (more accurately: every developer using it needs to re-sign).
Yep, true. Perfect for where you don't need that though.
Can I embed other venv libraries in this? Being able to ship a single file python+venv would be amazing!
How does it compare to Nuitka?
Also wondering - if I'm using several dynamic libs (.so/.dylib/.dll) is there a way to recompile them (given sources) and re-export their symbols from the what would be the main binary - this way producing single binary with exports, that still (through ctypes, cffi, etc. can lookup symbols)?
Very cool, even if it standard library only. I am frequently annoyed at the hoops I jump through to distribute Python onto Windows machines.