6 ms·

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

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=43500124 https://news.ycombinator.com/item?id=42463975 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.

benhurmarcel 2y ago
> 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.
- dagw 2y ago
  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.
- maxed 2y ago
  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.
dazzawazza 2y ago
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.
photonthug 2y ago
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 https://hugojosefson.github.io/docker-shebang/#python
networked 2y ago
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 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 https://pipx.pypa.io/stable/examples/#pipx-run-examples. pipx is much more widely packaged: https://repology.org/project/pipx/versions https://repology.org/project/pipx/versions.
- Gud 2y ago
  curl | sh is an abhorrent practice and should never be used.
  - tempaccount420 2y ago
    The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.
    - Gud 2y ago
      Why do you use 10 different distros that only get updated once in a blue moon?
      - dagw 2y ago
        I am not using 10 different OSs/distors, but across every potential user of my tool, it could very easily be 10+.
    - sgarland 2y ago
      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.
gcr 2y ago
A nitpick: uv’s package deduplication means virtualenvs do not take up space unless they have unique dependencies.
krupan 2y ago
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
samstave 2y ago
[dead]

benhurmarcel 2y ago

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

dagw 2y ago
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.
maxed 2y ago
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.

dazzawazza 2y ago

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.

photonthug 2y ago

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 https://hugojosefson.github.io/docker-shebang/#python

networked 2y ago

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 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 https://pipx.pypa.io/stable/examples/#pipx-run-examples. pipx is much more widely packaged: https://repology.org/project/pipx/versions https://repology.org/project/pipx/versions.

Gud 2y ago
curl | sh is an abhorrent practice and should never be used.
- tempaccount420 2y ago
  The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.
  - Gud 2y ago
    Why do you use 10 different distros that only get updated once in a blue moon?
    - dagw 2y ago
      I am not using 10 different OSs/distors, but across every potential user of my tool, it could very easily be 10+.
  - sgarland 2y ago
    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.

gcr 2y ago

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

krupan 2y ago

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

samstave 2y ago

[dead]