Live data from Hacker News

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

emily.space

181–190 of 1001 posts

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

#181
post #13
post #4

Another Python package manager? How many are there now?

> Another No, the same uv that people have been regularly ( https://hn.algolia.com/?q=uv ) posting about on HN since its first public releases in February of 2024 (see e.g. https://news.ycombinator.com/item?id=39387641 ). > How many are there now? Why is this a problem? The ecosystem has developed usable interoperable standards (for example, fundamentally uv manages isolated environments by using the same kind of vir…

It’s definitely an issue for learning the language. Obviously after working with python a bit that doesn’t matter, but fragmentation still makes it more of a hassle to get open source projects up and running if they don’t use something close to your usual package management approach.

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

#182

But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?

The pytorch ecosystem, for one, is notorious for very specific version dependencies between libraries.

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

#183
post #2

Idk, for me ruff was more of a game changer. No more explaining why we need both flake8 and pylint (and isort), no more flake8 plugins... Just one command that does it all. UV is great but I use it as a more convenient pip+venv. Maybe I'm not using it to it's full potential.

The dependencies descriptor is further structured, a requirements.txt is pretty raw in comparison.

But where it isn't a matter of opinion is, speed. Never met anyone who given then same interface, would prefer a process taking 10x longer to execute.

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

#184

But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?

What was wrong was that you needed to do that.

How many commands are required to build up a locally consistent workspace?

Modern package managers do that for you.

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

#185

But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?

How do pip and venv integrate with pyproject.toml? At least pip doesn't even use it.

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

#186

But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?

As mostly a Python outsider, in the infrequent times that I do use python package management, uv just works. When I use pip I’d get all sorts of obscure error messages that I’d have to go track down, probably because I got some obscure environment detail wrong. With uv I never run into that nonsense.

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

#188

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

>finally get a taste of npm

good god no thank you.

>cargo

more like it.

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

#189
post #63
post #29

These rust based tools really change the idea of what's possible (when you can get feedback in milliseconds). But I'm trying to figure out what Astral as a company does for revenue. I don't see any paid products on their website. They even have investors. So far it seems like they have a bunch of these high performance tools. Is this part of an upcoming product suite for python or something? Just curious. I'm not a f…

From "So how does Astral plan to make money? " ( https://news.ycombinator.com/item?id=44358216 ): "What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. An example of what this might look like [...] would be something like an enterprise-focused pri…

That doesn't really seem like a way to avoid getting "Broadcommed." Vertically integrated tooling is kind of a commodity.

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

#190
post #88
post #58

I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly. My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can't reproduce anything because just to…

You might be interested in pixi, which is roughly to conda as uv is to pip (also written in Rust, it reuses the uv solver for PyPI packages)

This is something that uv advocates should pay attention to, there are always contexts that need different assumptions, especially with our every growing and complex pile of libraries and systems.
Post reply on HN