Standalone executables without network at runtime

[aimarxjg]

🔘 Request type

User experience

🔘 Description

Because of the network Blocked， Hopefully there will be a portable version such as EXE .bat Thank you

[Tremeschin]

Ah, that's a really valid point for embedding full distributions on the executables than installing at runtime!

I remember trying this in the past, I know pyapp seems to support it, but I couldn't get it working back then. I'm worried of PyTorch and the depth estimators models on huggingface not being easily handled by this and still requiring network usage at runtime though

The releases would also be ~350 MB in size at best without torch, an a couple GB with it (cuda and rocm). I would likely hit github releases limits pretty quickly with this

I'll check for the feasibility of this nevertheless

[Tremeschin]

A man, sorry, I don't think this will be feasible to have, even experimentally

Explanation

I've got some ground work on this in BrokenSource/BrokenSource@b521253, it did work, with the caveat that most shared libraries (.dll on windows, .so on linux, .dylib on mac) were pointing to local files on my system

It would definitely fail to run in another system with any slightest deviation relative to mine; copying them over to the bundle creates relative paths spaghetti and isn't the way to go

One should look for static linked binaries for the interpreter as well. All venvs created in python but pyapp full isolation mode symlinks the python executable, so using those for the offline installer wouldn't work (which I did)

Also, the output files are just too big.. 1.9 GB baseline, 2.9 GB with CPU version of torch, CUDA would be ~4 GB or more, which kind of totally kills the point of caching stuff with uv for saving disk space and being fast. To add insult to injury, using PYAPP_FULL_ISOLATION which is required for it doesn't put Python under a venv and breaks a lot of assumptions and management already written and stable on the code

---

There's a chance..

I recognize your network blocking situation is non-ideal. You could try looking for a PyPI proxy in the mean time

I can see this whole situation being possible and beautifully solved if I/somebody forks pyapp and adds an ability to bundle multiple python wheels to be installed. I would happily write a code to find all needed dependencies and download them. This would actually be a better approach than resolving them at runtime and run into issues like #39, as the versions would be strictly predefined

This wouldn't solve huggingface though, or torch, at least for a single binary release I'm moving towards

[Tremeschin]

While my previous comments holds some truths, I managed to get fully offline installers working since then after forking pyapp and uv getting better over time, even with pytorch cpu being bundled in!

It's missing upscalers, ffmpeg (doable with imageio-ffmpeg package) and huggingface models (maybe set HF_HOME to a resources directory to be included in my final wheels), would bump from 430 MB to near 600 MB in file size

Haven't tested on windows, not sure where to host these or make it official. Also not sure how licensing goes.. Might have them available in the next release somewhere.

I like it because it doesn't touch uv cache and installs very fast because it comes in complete 🙂

Reopening for awareness