I've almost completely switched from "Python" to "uv run" | Hacker News Reader

I've almost completely switched from "Python" to "uv run"

actinium226.substack.com

23 pointsactinium22612 comments

Same here. The ability to specify dependencies and interpreter versions in the script and have the runtime just (quickly!) sort out all of the boring, uninteresting, brittle business around shims, virtualenvs, dependencies et al is absolutely game changing. I'm sure there are sharp edges I haven't found yet and that there will still be cross-platform compatibility issues which crop up but those will be addressed in due time.

Indeed, I've managed to find one cross-platform compatibility issue in that uv can't autoinstall python for musl for arm64, which I discovered when I tried to use it to install python in an alpine docker image on my M2 air. I didn't particularly need musl, I just wanted to save 50MB or so in my docker image so I went back to the slim version of the image I needed. But they're tracking this issue and there's so much effort going into making this tool better so I'm sure they'll get to it eventually.

Yep, it's the only sane option. Using uv takes Python from "oh no it's Python; how many hours am I going to spend working around pip bugs" to "hmm I might actually choose to use Python for this!".

uv is owned by a startup. I would not depend on it because they will pull some weird monetisation scheme in a few years.

Same with pydantic, that is now doing AI.

Well, kinda. I haven't used uv, so I'm not sure how strong the dependency (and the lock-in) is. But it looks like just a QoL tool that reads the standard pyproject.toml, etc. So, it shouldn't be that bad. And if the authors do something weird, you can always stay on an older version, fork it, or switch back to some alternative.

Considering how python is not very backwards compatibility friendly, that might not be an option.

I think, this is only relevant for staying on an older version of uv? Which is only a temporary solution, in any ecosystem and in almost any situation. It's just "even more temporary" in Python :)

If your old preferred alternative becomes unmaintained in the meantime and starts suffering from the same problems, that's basically equivalent to having to maintain a fork of uv. With the difference that it may be already out-of-date when the uv fork happens

Yeah that's definitely a concern, but uv is SO much better than it would be totally mad to avoid it just for that reason. I would say it is also so much better that if Astral does go out of business or try to ruin it that a fork is almost inevitable.

It reminds me of WhatsApp vs SMS. Sure, WhatsApp is owned by one company, but it's so much better than SMS that nobody sane stuck around using SMS. And sure Facebook have eventually started ruining it with the AI integration and apparently ads soon, but we've had over 10 years of an amazingly reliable, well-designed and free messaging platform. Easily worth it. If `uv` gives us something similar I don't care if they screw it up eventually.

I wish there was a way to force all deps to create folders in the same directory by default. Tired of seeing how many libraries feel entitled to write on your Home (which I like to have in a small partition and those big GB-sized files are not expected).

HOME=/tmp/ uv run

welp, nice simple solution lol, thanks!

You can take it one step further and make the file executable and place this at the top of the file:

#!/usr/bin/env -S uv run

Reply on news.ycombinator.com