Live data from Hacker News

Self-contained Python scripts with uv

blog.dusktreader.dev

51–60 of 114 posts

Re: Self-contained Python scripts with uv

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

Re: Self-contained Python scripts with uv

#52
post #51

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

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

Re: Self-contained Python scripts with uv

#53
post #21

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - I…

I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: im…

One of uv's justifications is that it isn't dependent on Python, and so there's no circular bootstrap problem. Things are now at the point with uv were you tell the person you're sharing a script with: 1. Get the install command from the uv site and run it (if they don't already have it installed). 2. Run the script with uv.

Literally cannot get simpler than that. Making uv an importable means assuming Python is present or easily installed on every system, which if it were the case then uv wouldn't be becoming a thing.

Re: Self-contained Python scripts with uv

#54
post #51

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

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

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.

Re: Self-contained Python scripts with uv

#55
post #3

Has anyone gotten this to work on Windows? I wanted to use this trick for some tooling for a game mod I'm working on but couldn't get the shebang trick to work.

I use this frequently on Windows and Linux. These are the steps I take: $> uv init --script .py $> uv add --script .py ... $> uv add --script .py --dev ... $> uv run .py Hope this helps :) Source: https://docs.astral.sh/uv/guides/scripts/

Unfortunately, `uv add --dev` doesn't work with `--script`:

  > uv -V
  uv 0.6.10
  > uv add --script foo.py --dev ruff
  error: the argument '--script ' cannot be used with '--dev'

  Usage: uv add --script  --link-mode  >

  For more information, try '--help'.
There is currently no mention of `uv add --script foo.py --dev ...` in https://docs.astral.sh/uv/guides/scripts/. Inline script metadata in Python doesn't standardize development dependencies.

I wrote a recent comment about how I develop scripts with `pyproject.toml` to have a regular development environment: https://news.ycombinator.com/item?id=43503171.

Re: Self-contained Python scripts with uv

#56
post #27

We do the same with Nix, the shebang line looks like this: #! nix-shell -i python3 -p "python312.withPackages (pkgs: [ pkgs.boto3 pkgs.click ])" With this, the only requirement is Nix on the system, you don't even need Python to be installed!

How to do the same thing with `nix shell` (The flake based command) instead of `nix-shell`?

Maybe `#! /usr/bin/env -S nix shell `?

Re: Self-contained Python scripts with uv

#57
post #51

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

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

Re: Self-contained Python scripts with uv

#58

Earlier quoted context omitted.

uv is licensed under either MIT or Apache-2.0[0] They can always stop developing or fork to a different license and all future work belongs under that license, but you can't back date licenses, so what exists is guaranteed Open Source. If you're super worried, you can create a fork and just keep it in sync. But this is essentially true about any other OSS project so I wouldn't be concerned. As far as I'm aware, conda…

Just because something is open source doesn't mean it will be maintained. With uv there is the slight peculiarity that it's written in Rust rather than Python. So you need to count on there being an active group of Rust devs who care about Python. Because it uses PyPI I'm happy to use it as a package manager and dev tool. The worst that can happen is I have to switch back to pip etc. But I wouldn't use it as package…

The really great thing is that the inline metadata format is an accepted PEP spec, so even if uv goes down the tubes there will be other tools that can be dropped in to support it.

Re: Self-contained Python scripts with uv

#60

So now I have to make sure uv is installed instead of python. Whar us this better? And python is available on almost any system

Python is not a globally available thing. I was really surprised when I setup Kubuntu 24.04 and found it missing. And now you can do `uv run --python= ...` and have all that automatically handled on a case by case basis.
Post reply on HN