alternatively, uv lets you do this:

  #!/usr/bin/env -S uv run --script
  #
  # /// script
  # requires-python = ">=3.12"
  # dependencies = ["foo"]
  # ///

The /// script block is actually specified in PEP 723 and supported by several other tools apart from uv.

The last time I commented extolling the virtues of uv on here, I got a similar reply, pointing out that PEP 723 specs this behavior, and uv isn’t the only way. So I’ll try again in this thread: I’m bullish on uv, and waiting for Cunningham.

I am all in on uv as well, and advocating for its use heavily at $dayjob. But I think having as much as possible of these things encoded in standards is good for the ecosystem. Maybe in a few years time, someone will make something even better than uv. And in the meantime, having things standardised speeds up adoption in e.g. syntax highlighting in editors and such.

That's good to hear; do you know what other tools support it?

From what I can tell, Hatch, PDM, pipx and pip-run also support it.

I’ve started migrating all of my ~15 years of one-off python scripts to have this front matter. Right now, I just update when/if I use them. I keep thinking if were handier with grep/sed/regex etc, I’d try to programmatically update .pys system-wide. But, many aren’t git tracked/version controlled, just laying in whatever dir they service(d). I’ve several times started a “python script dashboard” or “hacky tools coordinator” but stop when I remember most of these are unrelated (to each-other) and un/rarely used. I keep watching the chatter and thinking this is probably an easy task for codex, or some other agent but these pys are “mine” (and I knew^ how they worked when I wrote^ them) and also, they’re scattered and there’s no way I’m turning an agent loose on my file system.

^mostly, some defs might have StackOverflow copy/pasta

You could run ripgrep on your file system root to find most of them, its insanely fast, then feed it to claude or something to generate a script to do it for you.

This is an awesome features for quick development.

I'm sure the documentation of this featureset highlights what I'm about to say but if you're attracted to the simplicity of writing Python projects who are initialized using this method, do not use this code in staging/prod.

If you don't see why this is not production friendly it's for the simple a good.reaaon that creating deployable artifacts packaging a project or a dependency of a project this uses this method, creating reproducible builds becomes impossible.

This will also lead to builds that pass your CI but fail to run in their destination environment and vice versa due to the fact that they download heir dependencies on the fly.

There may be workarounds and I know nothing of this feature so investigate yourself if you must.

My two cents.

This isn't really "alternatively"; it's pointing out that in addition to the shebang you can add a PEP 723 dependency specification that `uv run` (like pipx, and some other tools) can take into account.

I'm actually a bit annoyed that uv won. I found pdm to be a really nice solution that fixed a lot of the issues poetry had without the hard ideological stance behind it, while fixing most of its problems. But maybe that ideology was partly what drove it's adoption.

Rust is getting this feature too, it's great for one off scripts

Yeah, but you need `uv`. If we are reaching out for tools that might not be around, then you can also depend on nix-shell,

    #! /usr/bin/env nix-shell
    #! nix-shell -i python3 --packages python3

Yeah, but you need Nix. If we are reaching out for tools that might not be around, then you can also depend on `curl | sudo bash` to install Nix when not present.

(this is a joke btw)

Yeah, but you need curl, sudo, and bash…

"Give me a 190-byte hex0 seed of x86 assembly, and I shall compile the rest of the world." - Archimedes

amazing quote. Adding it to my about page, do you want credit or shall I credit it to archimedes xD

On a serious note, its so brilliant that something like this is now possible when we think about it. It's maddeningly crazy to think about all the process but in the end that you can end up with a system / linux iso whose hash you can trust/independently verify and then you use it and spread around the world. Definitely makes me feel as sky's the only limit or just its very pleasant to think about it.

The issue I have with `nix-shell` is that the evaluation time is long, so if you need to run the script repeatedly it may take a long time. `nix shell` at least fix this issue by caching evaluations, but I think uv is still faster.

As shared in a sibling comment, you can get away with just curl+shell: https://paulw.tokyo/standalone-python-script-with-uv/

This comes with the added benefit that your environment is reverted as soon as you exit the Nix shell.

I dont think your emvironment is permanently changed with uv run?

Where does uv download the Python interpreter to?

That shebang will work on GNU link based systems, but might not work elsewhere. I know that’s the most popular target, but not working on macOS, BSDs, or even busybox.

I just tried the one you are replying to and it worked great on macOS. I frequently use a variant of this on my Mac.

That’s interesting. I wonder when that changed. Maybe FreeBSD supports multi arg shebangs now, too

The -S argument to env splits the argument on whitespace.

The shell doesn't support anything, it just passes the string to env.

So beware quoting and other delimiters that won't work the way you expect.

And with some small shebang trick, you don't even need to have uv installed [1], just curl and a posix shell

[1] https://paulw.tokyo/standalone-python-script-with-uv/

> Then you don't even need python installed. uv will install the version of python you specified and run the command

What you meant was, "you don't need python pre-installed". This does not solve the problem of not wanting to have (or limited from having) python installed.