Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

211–220 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#211

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

poetry gave us lock files and consistent installs for years. uv is much, much faster however.

I have to agree that there were a lot of good options, but uv's speed is what sets it apart.

Also the ability to have a single script with deps using TOML in the headers super eaisly.

Also Also the ability to use a random python tool in effectively seconds with no faffing about.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#212
post #95

I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat. I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project. I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python enviro…

> how much I prefer prepending "uv" to everything instead of activating environments You can also prepend the path to the virtual environment's bin/ (or Scripts/ on Windows). Literally all that "activating an environment" does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means mod…

Yup. I never even use activate, even though that's what you find in docs all over the place. Something about modifying my environment rubs me the wrong way. I just call ``./venv/bin/python driver.py`` (or ``./venv/bin/driver`` if you install it as a script) which is fairly self-evident, doesn't mess with your environment, and you can call into as many virtualenvs as you need to independently from one another.

``uv`` accomplishes the same thing, but it is another dependency you need to install. In some envs it's nice that you can do everything with the built-in Python tooling.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#213
uv is great. I am a Ruby developer and I always loathed having to work with Python libraries because of how bad the tooling was. It was too complex to learn for the one-off times that I needed it and nothing worked properly.

Now with uv everything just works and I can play around easily with all the great Python projects that exist.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#214

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

Webdev since 1998 here. Tabling the python vs JS/etc to comment on npm per se. PNPM is better than npm in every way. Strongest possible recommendation to use it instead of npm; it's faster, more efficient, safer, and more deterministic. See https://pnpm.io/motivation

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#215
post #193

Earlier quoted context omitted.

poetry gave us lock files and consistent installs for years. uv is much, much faster however.

I used poetry professionally for a couple of years and hit so many bugs, it was definitely not a smooth experience. Granted that was probably 3-4 years ago.

I've occasionally run into performance issues and bugs with dependency resolution / updates. Not so much recently, but at a previous company we had a huge monorepo and I've seen it take forever.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#216

Does speed really matter during python installation?

On my system, Pip takes noticeable time just to start up without ultimately doing anything of importance:

  $ time pip install
  ERROR: You must give at least one requirement to install (see "pip help install")

  real 0m0.356s
  user 0m0.322s
  sys 0m0.036s
(Huh, that's a slight improvement from before; I guess pip 25.3 is a bit better streamlined.)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#217

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

> you should just use virtualenv with pip This is the most insulting take in the ongoing ruination of Python. You used to be able to avoid virtualenvs and install scripts and dependencies directly runnable from any shell. Now you get endlessly chastised for trying to use Python as a general purpose utility. Debian was a bastion of sanity with the split between dist_packages and site_packages but that's ruined now too…

it's because so many essential system tools now rely on python, and if you install arbitrary code outside of a venv it can clobber the global namespace and break the core OS' guarantees.

I do agree it is annoying, and what they need to do is just provide an automatic "userspace" virtualenv for anything a user installs themselves... but that is a pandoras box tbh. (Do you do it per user? How does the user become aware of this?)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#218
post #69

Am I the only one who feels like this is obviated by Docker? uv is a clear improvement over pip and venv, for sure. But I do everything in dev containers these days. Very few things get to install on my laptop itself outside a container. I've gotten so used to this that tools that uninstall/install packages on my box on the fly give me the heebie-jeebies.

Lots of people are doing things where they would prefer not to invoke the weight of an entire container.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#219

Earlier quoted context omitted.

Installing an out-of-distro deb/rpm/msi/dmg/etc package is just as unsafe as curl|sh. Or even unsafer, as packages tend to require root/admin.

Security and auditability is not the core problem, it's versioning and uninstalling. https://docs.sweeting.me/s/against-curl-sh

Uninstalling can be a problem.

Versioning OTOH is often more problematic with distro package managers that can't support multiple versions of the same package.

Also inability to do user install is a big problem with distro managers.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#220

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

I've been using pip-tools for the best part of a decade. uv isn't the first time we got lock files. The main difference with uv is how it abstracts away the virtualenv and you run everything using `uv run` instead, like cargo. But you can still activate the virtualenv if you want. At that point the only difference is it's faster.
Post reply on HN