Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies.

Sure, there’s Nix... if you’ve already transcended time, space, and the Nix manual. Docker? Great, if downloading a Linux distro to run sed sounds reasonable.

There’s got to be a middle ground simple, declarative, and built for humans.

https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

And there was a March discussion of a different blog post:

https://news.ycombinator.com/item?id=43500124

I hope this stays on the front page for a while to help publicize it.

And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than pip.

It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheless.

Hopefully more languages follow suit on this pattern as it can be extremely useful for many cases, such as passing gists around, writing small programs which might otherwise be written in shell scripts, etc.

[0] https://rust-lang.github.io/rfcs/3424-cargo-script.html

I still do because:

- Go gives me a single binary

- Dependencies are statically linked

- I don’t need any third-party libs in most scenarios

- Many of my scripts make network calls, and Go has a better stdlib for HTTP/RPC/Socket work

- Better tooling (built-in formatter, no need for pytest, go vet is handy)

- Easy concurrency. Most of my scripts don’t need it, but when they do, it’s easier since I don’t have to fiddle with colored functions, external libs, or, worse, threads.

That said, uv is a great improvement over the previous status quo. But I don’t write Python scripts for reasons that go beyond just tooling. And since it’s not a standard tool, I worry that more things like this will come along and try to “improve” everything. Already scarred and tired in that area thanks to the JS ecosystem. So I tend to prefer stable, reliable, and boring tools over everything else. Right now, Go does that well enough for my scripting needs.

If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell .

So I still don’t see what the fuss is about?

I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI setup times.

  $ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python
  >>> from script import X

  $ uv run --with-script script.py python

  $ "$(uv python find --script script.py)"
  >>> from script import X

I think their docs could use a little bit of work, especially there should be a defined path to switch from a requirements.txt based workflow to uv. Also I felt like it's a little confusing how to define a python version for a specific project (it's defined in both .python-version and pyproject.toml)

For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept.

When Python first came out, our processors were 80486 at best and RAM was measured in MB at roughly £30/MB in the UK.

"For the longest time, ..." - all distros have had scripts that find the relevant Python or Java or whatevs so that's simply daft. They all have shebang incantations too.

So we now have uv written in Rust for Python. Obviously you should install it via a shell script directly from curl!

I love all of the components involved here but please for the love of a nod to security at least suggest that the script is downloaded first, looked over and then run.

I recently came across a Github hosted repo with scripts that changed Debian repos to point somewhere else and install ... software. I'm sure that's all fine too.

curl | bash is cute and easy and very, very insecure.

    #!/usr/bin/env bash
    eval "$(conda shell.bash hook)"
    conda activate myenv
    python myscript

As Ive gotten older I've grown weary of third party tools, and almost always try to stick with the first party built in methods for a given task.

Does uv provide enough benefit to make me reconsider?

uv is the magic that deals with all of the rough edges/environment stuff I usually hate in Python. All I need to do is `uv run myFile.py` and uv solves everything else.

    #!/usr/bin/env -S mise x xh jq fzf gum -- bash
    todo=$(xh 'https://jsonplaceholder.typicode.com/todos' | jq '.[].title' | fzf)
    gum style --border double --padding 1 "$todo"

(also: possible there's always been a way and I'm an idiot)

Firstly, I have been a HN viewer for so many time and this is the one thing about pep python scripts THAT always get to the top of leaderboard of hackernews by each person discovering it themselves.

I don't mean to discredit the author. His work was simple and clear to understand. I am just sharing this thesis that I have that if someone wants karma on Hackernews for whatever reason, this might be the best topic. (Please don't pitchfork me since I don't mean offense to the author)

Also, can anybody please explain to me on how to create that pep metadata in uv from just a python script and without anything else, like some command which can take a python script and give pep and add that in the script, I am pretty sure that uv has a feature flag but I feel that the author might've missed out on this feature because I don't know when coding one off scripts in python using AI (gemini) it had some options with pep so I always had to paste uv's documentation I don't know, so please if anybody knows a way to create pep easier using the cli, then please tell me! Thanks in advance!!

The downside is that there are a bunch of seemingly weird lines you have to paste at the begging of the script :D

If anyone is curios it's on pypi (pysolate).

Note that PEP 723 is also supported by pipx run:

https://pipx.pypa.io/latest/examples/#pipx-run-examples

I'm building yt-dlp / uvx based WebUI

- https://github.com/ocodo/uvxytdlp

Still work in progress but shaping up nicely.

Also that would be reproducible, in contrast to what is shown in the blog post. To make that reproducible, one would have to keep the lock file somewhere, or state the checksums directly in the Python script file, which seems rather un-fun.

Some Python devs told me, it's an awesome language, but they envy the Node.js ecosystem for their package management.

Seems like uv finally removed that roadblock.

Can you not use `uvx` with your script because it only works on packages that are installed already or on PyPi?

I like it though. It's very convenient.

Bruh, one-off scripts is the whole point of Python. The cheat code is to add "break-system-packages = true" to ~/.config/pip/pip.conf. Just blow up ~/.local/lib/pythonX.Y/site-packages/ if you run into a package conflict (exceedingly rare) and reinstall. All these venv, uv, metadata peps, and whatnot are pointless complications you just don't need.

That's bait! / Ads are getting smarter!

I would also have accepted "unless you're geh", "unless you're a traitor to the republic", "unless you're not leet enough" etc.

Is there a version of uv written in Python? It's weird (to me) to have an entire ecosystem for a language and a highly recommended tool to make your system work is written in another language.