Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Best practice to distribute private Python CLI tools in a team
4 points by oulipo on Jan 28, 2025 | hide | past | favorite | 11 comments
I'm wondering what would be the best practice today to distribute a CLI tool to an internal team?

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"?



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.


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.


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...


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 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


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).


Docker container? It’s heavier but requires no local env considerations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: