Uv Is the Best Thing to Happen to the Python Ecosystem in a Decade

uv is probably much more of a game changer for beginner python users who just need to install stuff and don't need to lint. So it's a bigger deal for the broader python ecosystem.

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.

You aren't, but that's fine. Everyone has their own idea about how tooling should work and come together, and I happen to be in your camp (from what I can tell). I actively don't want an all-in-one tool to do "project management".

What strikes me about uv is that it seems to understand that not everyone launching a Python-based project has a CS degree. That accessibility matters—especially in the era where more non-engineers are building products.

Curious: for those who've switched to uv, did you notice any friction when collaborating with team members who were still on traditional setups? I'm thinking about adoption challenges when you're not a solo builder.

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 virtual environment created by the standard library — because that's the only kind that Python cares about; the key component is the `pyvenv.cfg` file, and Python is hard-coded to look for and use that); and you don't have to learn or use more than one.

There are competing options because people have different ideas about what a "package manager" should or shouldn't be responsible for, and about the expectations for those tasks.

For me package installation is way, way faster with uv, and I appreciate not needing to activate the virtual environment.

I'm interested if you have any technical documentation about how conda environments are structured. It would be nice to be able to interact with them. But I suspect the main problem is that if you use a non-conda tool to put something into a conda environment, there needs to be a way to make conda properly aware of the change. Fundamentally it's the same issue as with trying to use pip in the system environment on Linux, which will interfere with the system package manager (leading to the PEP 668 protections).

uv has implemented experimental support, which they announced here [3].

[0] https://wheelnext.dev/proposals/pepxxx_wheel_variant_support...

[1] https://us.pycon.org/2025/schedule/presentation/100/

[2] https://www.youtube.com/watch?v=1Oki8vAWb1Q

[3] https://astral.sh/blog/wheel-variants

The "install things that have complex non-Python dependencies using pip" story is much better than several years ago, because of things like pip gaining a new resolver in 2020, but in large part simply because it's now much more likely that the package you want offers a pre-built wheel (and that its dependencies also do). A decade ago, it was common enough that you'd be stuck with source packages even for pure-Python projects, which forced pip to build a wheel locally first (https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-...).

Another important change is that for wheels on PyPI the installer can now obtain separate .metadata files, so it can learn what the transitive dependencies are for a given version of a given project from a small plain-text file rather than having to speculatively download the entire wheel and unpack the METADATA file from it. (This is also possible for source distributions that include PKG-INFO, but they aren't forced to do so, and a source distribution's metadata is allowed to have "dynamic" dependencies that aren't known until the wheel is built (worst case) or a special metadata-only build hook is run (requires additional effort for the build system to support and the developer to implement)).

Currently they are a bit pointless. Sure they aid in documentation, but they are effort and cause you pain when making modifications (mind you with halfarse agentic coding its probably less of a problem. )

What would be better is to have a strict mode where instead of duck typing its pre-declared. It would also make a bunch of things faster (along with breaking everything and the spirit of the language)

I still don't get the appeal of UV, but thats possibly because I'm old and have been using pyenv and venv for many many years. This means that anything new is an attack on my very being.

however if it means that conda fucks off and dies, then I'm willing to move to UV.

It's the python version of fink vs macports vs homebrew. Or apt vs deb. or pkgsrc vs ports.

But I don't think "its just another" gets the value proposition here. It's significantly simpler to deploy in practice for people like me, writing ad hoc scripts and running git downloaded scripts and codelets.

Yes, virtualenv and pip existed. No, they turned out to be a lot more fiddly to run in practice than UV.

That UV is rust is funny, but not in a terrible way. The llvm compiler toolchain is written in C but compiles other languages. Using one language to do things for another language isn't such a terrible outcome.

I hope UV supplants the others. Not to disrespect their authors, but UV is better for end users. If its worse for package maintainers I think the UV authors should be told.

/just guessing, haven't tried it

Maybe if you trust the software, then trusting the install script isn't that big of a stretch?

no. thats how you get malware. Make a package. Add it to a distro. then we will talk.

You can `pip install uv` or manually download and extract the right uv-*.tar.gz file from github: https://github.com/astral-sh/uv/releases

Also, most reasonable developers should already be running with the ExecutionPolicy RemoteSigned, it would be nice if code signing these install script was a little more common, too. (There was even a proposal for icm [Invoke-Command] to take signed script URLs directly for a much safer alternative code-golfed version of iwr|iex. Maybe that proposal should be picked back up.)

This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this if UV had a way to whitelist specific dependencies/dependency versions.

As long as you have internet access, and whatever repository it's drawing from is online, and you may get different version of python each time, ...

It will install and use distribution packages, to use PyPA's terminology; the term "module" generally refers to a component of an import package. Which is to say: the names you write here must be the names that you would use in a `uv pip install` command, not the names you `import` in the code, although they may align.

This is an ecosystem standard (https://peps.python.org/pep-0723/) and pipx (https://pipx.pypa.io) also supports it.

I want to be able to ship a bundle which needs zero network access to run, but will run.

It is still frustratingly difficult to make portable Python programs.

But whoever runs this has to install uv first, so not really standalone.

(sadly, uv cannot detect the release date of some packages. I'm looking at you, yaml!)

uv is MIT licensed so if they rug pull, you can fork.

Speaking of history, I was very sympathetic to the "we are open-source volunteers, give us a break" kind of stuff for the first N years.. but pypa has a pattern of creating problems, ignoring them, ignoring criticism, ignoring people who are trying to help, and pushing talent+interest elsewhere. This has fragmented the packaging ecosystem in a way that confuses newcomers, forces constant maintenance and training burden on experts, and damages the credibility of the language and its users. Hatch is frankly too little too late, and even if it becomes a wonderful standard, it would just force more maintenance, more confusion for a "temporary" period that lasts many, many years. Confidence is too far gone.

As mentioned elsewhere in the thread, there are tons of conflicting tools in the space already, and due to the fragmentation, poetry etc could never get critical mass. That's partly because pypa stuff felt most "official" and a safer long term bet than anything else, but partly because 33% better was never good enough to encourage widespread adoption until it was closer to 200% better. But uv actually IS that much better. Just let it win.

And let pypa be a case-study in how to NOT do FOSS. Fragmentation is fine up to a point, but you know what? If it wasn't for KDE / Gnome reinventing the wheel for every single kind of individual GUI then we'd have already seen the glorious "year of the linux desktop" by now.