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.

Why do you use 10 different distros that only get updated once in a blue moon?

I am not using 10 different OSs/distors, but across every potential user of my tool, it could very easily be 10+.

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.

It's often both useful and appropriate in Dockerfiles.

That this is normal docker practice just confirms my belief that docker is to be avoided.

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.

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

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

A nitpick: uv’s package deduplication means virtualenvs do not take up space unless they have unique dependencies.

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