It was unclear to me after a superficial reading - is there a story for packing non standard-library dependencies? Let's say I need library X + my own code. Is there currently possible to ship pyoxy + a tar file of all the extra code? What about libraries with C (numpy and friends)?
Very cool, even if it standard library only. I am frequently annoyed at the hoops I jump through to distribute Python onto Windows machines.
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?
>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:
- Install Python system wide
- Ensure there is Python venv + pip + (QoL) virtualenvwrapper
- Create virtual environment per program
- Load up my code
Not horrible, but if I could package Python + extra code into a zip file, I could just create foobar-v20220512.zip send that to anybody, and have them unzip the entire program into the same directory every time. Then they could do it without admin privileges and with the most minimal of user training. Easy versioning to boot.
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.
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!
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.
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.
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.
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.