←back to thread

uv: An extremely fast Python package and project manager, written in Rust

(github.com)
741 points chirau | 5 comments | 23 Jun 25 16:27 UTC | HN request time: 0.001s | source
Show context
theLiminator ◴[23 Jun 25 17:43 UTC] No.44358222[source]▶
uv and ruff are a great counterexample to all those people who say "never reinvent the wheel". Don't ever do it just for the sake of doing it, but if you have focused goals you can sometimes produce a product that's an order of magnitude better.
replies(7): >>44358352 #>>44358435 #>>44358583 #>>44358604 #>>44360352 #>>44361046 #>>44362201 #
0cf8612b2e1e ◴[23 Jun 25 18:09 UTC] No.44358435[source]▶
The history of Python package management is clear that everyone thinks they can do a better job than the status quo.
replies(5): >>44358452 #>>44358893 #>>44359071 #>>44361572 #>>44362012 #
nickelpro ◴[23 Jun 25 19:16 UTC] No.44359071[source]▶
uv is purely a performance improvement, it changes nothing about the mechanics of Python environment management or packaging.

The improvements came from lots of work from the entire python build system ecosystem and consensus building.

replies(2): >>44359240 #>>44359656 #
globular-toast ◴[23 Jun 25 20:20 UTC] No.44359656[source]▶
Actually not true. One of the main differences with uv is you don't have to think about venvs any more. There's a talk about it from one of the authors at a recent PyCon here: https://www.youtube.com/watch?v=CV8KRvWKYDw (not the same talk I linked elsewhere in the thread).
replies(1): >>44360151 #
nickelpro ◴[23 Jun 25 21:10 UTC] No.44360151[source]▶
How do you think uv works?

It creates a venv. Note were talking about the concept of a virtual environment here, PEP 405, not the Python module "venv".

replies(3): >>44361997 #>>44363448 #>>44363822 #
lmm ◴[24 Jun 25 01:27 UTC] No.44361997[source]▶
The implementation details don't matter. uv might follow PEP 405 but it could work just as well without doing so. The point is that it doesn't give you the bunch of extra footguns that any other Python package management does.
replies(1): >>44362387 #
1. nickelpro ◴[24 Jun 25 02:34 UTC] No.44362387[source]▶
It matters immensely that it follows PEP 405, it makes uv the implementation detail. You can swap out uv for any other project management tool or build frontend and change nothing needs to change about the development environment.

This is the entire purpose of the standards.

replies(1): >>44362587 #
2. lmm ◴[24 Jun 25 03:16 UTC] No.44362587[source]▶
> You can swap out uv for any other project management tool or build frontend and change nothing needs to change about the development environment.

> This is the entire purpose of the standards.

That seems to amount to saying that the purpose of the standards is to prevent progress and ensure that the mistakes of early Python project management tools are preserved forever. (Which would explain some things about the last ~25 years of Python project management I guess). The parts of uv that follow standards aren't the parts that people are excited about.

replies(3): >>44364533 #>>44365079 #>>44369065 #
3. dagw ◴[24 Jun 25 10:08 UTC] No.44364533[source]▶
The parts of uv that follow standards aren't the parts that people are excited about.

I disagree. Had uv not followed these standards and instead gone off and done their completely own thing, it could not function as a drop in replacement for pip and venv and wouldn't have gotten anywhere near as much traction. I can use uv personally to work on projects that officially have to support pip and venv and have it all be transparent.

4. aragilar ◴[24 Jun 25 11:43 UTC] No.44365079[source]▶
uv only exists because of those standards and therefore can make assumptions that earlier tools could not.
5. nickelpro ◴[24 Jun 25 18:14 UTC] No.44369065[source]▶
There are no parts of uv that don't follow standards.

The standards have nothing to do with the last 25 years of Python project management, the most import ones (PEP 517/518) are less than 10 years old.