This has come up a LOT on HN in the past few months, some other recent examples:
https://news.ycombinator.com/item?id=43500124
https://news.ycombinator.com/item?id=42463975
I like uv and all, but I take exception to the "self-contained" claim in two regards:
1) The script requires uv to already be installed. Arguably you could make it a shell script that checks if uv is already installed and then installs it via curlpipe if not... but that's quite a bit of extra boilerplate and the curlpipe pattern is already pretty gross on its own.
2) Auto-creating a venv somewhere in your home directory is not really self-contained. If you run the script as a one-off and then delete it, that venv is still there, taking up space. I can't find any assertion in the uv docs that these temporary virtual environments are ever automatically cleaned up.
Right, you need to have uv installed, and if you don't, you'll probably have to install it manually or through `curl | sh`. I think this is a valid complaint. Something to consider is that it will become less of an issue as package managers include uv in their repositories. For example, uv is already available in Alpine Linux and Homebrew: https://repology.org/project/uv/versions.
Another thing is that inline script metadata is a Python standard. When there is no uv on the system and uv isn't packaged but you have the right version of Python for the script, you can run the script with pipx: https://pipx.pypa.io/stable/examples/#pipx-run-examples. pipx is much more widely packaged: https://repology.org/project/pipx/versions.
curl | sh is an abhorrent practice and should never be used.
The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.
No, the alternative is to package it yourself and offer it with a signing key. If you make a .deb and .rpm, you’ve covered a large majority of end users.
That sounds worse than the status quo, a lot of developers use Arch Linux, NixOS, other uncommon (to non-devs) distros.
Why is signing key with .deb/.rpm better than `curl | sh` from a HTTPS link on a domain owned by the author? .deb/.rpm also contain arbitrary shell commands.
If the shell script happens to have key verification built in to it, then not much from the perspective of provenance verification, but that’s rare IME. Also, using the OS’s package manager means that you can trivially uninstall it.
I tried to hack together a shebang with docker+uv to solve this kind of problem, and it sort of does because that’s maybe more common than uv for a random dev machine (especially since tfa says it’s a gong project).
This works but doesn’t cache anything so the download for every run is awkward. This can probably be fixed with a volume tho?
Something like this: https://hugojosefson.github.io/docker-shebang/#python
You usually have to install something before you can run a program on your computer, so installing uv doesn't seem that bad to me. I still wouldn't call this self-contained because when you run the program it downloads who knows what from the internet!
To me, fully self-contained is something more like an AppImage
Agree 100%. Using something like py2exe creates a self contained "python script". This comes with a lot of problems for the developer but minimum problems for the user.
A nitpick: uv’s package deduplication means virtualenvs do not take up space unless they have unique dependencies.
> I can't find any assertion in the uv docs that these temporary virtual environments are ever automatically cleaned up.
That’s a good point. I wonder if at least they are reused when you run the script several times.
I took a closer look; uv installs the inline required packages in it's cache directory `~/.cache/uv` (if they are not already there). So the packages will probably exist until the cache is cleared with for example `uv clear`.
It's not that the inline requirements make a new `.venv` directory or something, uv seems to link the packages to a central location and reuse them if already there.
My understanding is that uv creates a hash of the script name, python version and dependencies when creating the venv. So if none of those change, it will reuse the venv.