Uv: Running a script with dependencies

shebang mode is also incredibly useful and allows execution like ./script.sh

  #!/usr/bin/env -S uv run --script
  # /// script
  # dependencies = [
  #   "requests<3",
  #   "rich",
  # ]
  # ///
  import requests, rich
  # ... script goes here

PEP723 is also supported by pipx and hatch, even though uv is (deservedly) getting all the attention these days.

Others like pip-tools have support in the roadmap (https://github.com/jazzband/pip-tools/issues/2027)

I thought that was a heart emoticon next to requests, for a second.

This is cool, but honestly I wish it was builtin language syntax not a magic comment, magic comments are kind of ugly. Maybe some day…

(I realise there are some architectural issues with making it built-in syntax-magic comments are easier for external tools to parse, whereas the Python core has very limited knowledge of packaging and dependencies… still, one of these days…)

This is cool!

This gave me the questionable idea of doing the same sort of thing for Go: https://github.com/imjasonh/gos

(Not necessarily endorsing, I was just curious to see how it would go, and it worked out okay!)

But don't you have to only ever run it once to have the deps/venv for subsequent runs?

If I may interject, does anyone have any idea why the `-S` flag is required? Testing this out on my machine with a BSD env, `/usr/bin/env -S uv run --python 3.11 python` and `/usr/bin/env uv run --python 3.11 python` do the same thing (launch a Python interactive shell). Man page for env doesn't clarify a lot to me, as the end result still seems to be the same("Split apart the given string into multiple strings, and process each of the resulting strings as separate arguments to the env utility...")

Completely agree. UV for stalled what was going to be a major project to move lots of python to golang. There will still be a lot migrated, but smaller script like things are no longer in scope.

I honestly believe this is a killer (killer) feature.-

There is also marimo. For my use cases it has been a fantastic upgrade from Jupyter. I use it in the style of TFA (notebooks are just Python files). In the notebook UI, you can add packages to the script headers. It's so nice to have many notebooks in one directory with independent, but reproducible environments.

Marimo notebooks are easy to diff when committing to git. Plus you get AI coding assistants in the notebook, a reactive UI framework, the ability to run in the browser with Pyodide on WASM, and more. It will also translate your old Jupyter notebooks for you.

For me, what uv is to package managers, marimo is to notebooks.

https://docs.astral.sh/uv/guides/integration/marimo/

What’s your use case for locking dependencies on a single script?

One things that’s useful to my organization is that we can then proceed to scan the lockfile’s declared dependencies with, e.g., `trivy fs uv.lock` to make sure we’re not running code with known CVEs.

There's a lot of small one off things where deploying uv and the script makes it easy to use. A lot of use cases for golang can be replaced with uv.

I had the same sentiment, but uv seems to have eliminated the competition. Installing uv using your OS package manager is enough as it can also download and install (isolated) Python interpreters as well.

I wish they would make uv default and end this game.

I recommend trying it, it gets a ton of hype but I think for good reason.

This is the one.

imo all I usually need is pip-tools and venv, but uv kind of bundles the two together in a very natural way (and is very fast)

I don't know if there's an official reason, but my guess is that it's slightly out of scope for pip: pip is a packaging installation tool, not a virtual environment managing system.

uv, being both, is a more natural fit for an implementation of that PEP.

Here's a relevant discussion: https://discuss.python.org/t/idea-introduce-standardize-proj...