Ask HN: Best practice to distribute private Python CLI tools in a team
12 comments
So after looking for many alternatives, I think what I'd do now is use `mise` and/or `aqua` which seem well-designed exactly for that purpose, and can handle various stacks (python, js, etc)
I'd build it around pip and just accept that your users will have to install python and do the one-time pip install. Just do
pip install <package_name> -U
to get the latest.
pip install <package_name> -U
to get the latest.
Then I guess I might as well expect them to use `uv` and use `uv tool`
Yea, sorry I'm not too familiar with uv yet, but sounds like it could work well. The latest would be installed each invocation. The trick though would be pointing to your private pip repository.
I use PyInstaller to distribute a Qt5-based GUI app, and some associated CLI tools. It's fairly easy to configure, and works out fine.
I've tried this but never got the PyInstaller deployment process down smooth enough for my taste. Even for small apps, I end up rewriting in C# to compile executables with if I need to deploy to people who don't use code. With PyInstaller, since you have to package the Python interpreter the .exe always ends up too large and slow for my taste (especially since I usually compile with --onefile. I'm wondering how you do it, if you use onefile or have some better way to run PyInstaller so the final exe is smaller or faster.
I use -F (--onefile).
It's certainly not fast to start, but in my case, it's not a quick one-and-done type thing, so I don't mind too much
It's certainly not fast to start, but in my case, it's not a quick one-and-done type thing, so I don't mind too much
How big is your distribution file? I tried this but my project had numpy and pandas and the distributable was like 350 MB!
I have Qt, but not numpy or pandas. My executable is 40MB (still big).
Can you easily combine it into one file? You could use PEP 723 and `uv`'s script running capability [0].
If your project is not flat, you could have a "build" step to combine everything into one file (assuming everything is simple).
`uv tool` would be great but you'd need to manage a private repo and credentials -- the "it just works" magic kinda goes away at that point.
[0] https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
If your project is not flat, you could have a "build" step to combine everything into one file (assuming everything is simple).
`uv tool` would be great but you'd need to manage a private repo and credentials -- the "it just works" magic kinda goes away at that point.
[0] https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
Docker container? It’s heavier but requires no local env considerations.
I think `uv` with `uv tool` and `uv tool upgrade` might be quite interesting, coupled with either private git repo, or a private pip repo
is there a way to package the python app so that people in the team are not required to have a working Python installation at first? to avoid issues with dependencies, or "doesn't work on my machine", etc?
also is there a "best practice" or existing lib for the python program to auto-detect that the package has a newer version (eg a new Github release) and then when quitting tells the user "A new version is available, run `mytool --update` to update"?