Most active commenters
  • nickelpro(6)
  • lmm(3)

←back to thread

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

(github.com)
740 points chirau | 23 comments | 23 Jun 25 16:27 UTC | HN request time: 1.223s | source | bottom
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 #
1. 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 #
2. psunavy03 ◴[23 Jun 25 18:10 UTC] No.44358452[source]▶
In this case, they were right.
replies(1): >>44363104 #
3. henry700 ◴[23 Jun 25 18:57 UTC] No.44358893[source]▶
Of course they do, this tends to happen when the history is it being hot flaming garbage.
4. 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 #
5. 0cf8612b2e1e ◴[23 Jun 25 19:36 UTC] No.44359240[source]▶
Disagree in that uv makes switching out the underlying interpreter so straightforward. Becomes trivial to swap from say 3.11 to 3.12. The pybi idea.

Sure, other tools could handle the situation, but being baked into the tooling makes it much easier to bootstrap different configurations.

replies(1): >>44359250 #
6. nickelpro ◴[23 Jun 25 19:37 UTC] No.44359250{3}[source]▶
Yes, it's faster and better than pyenv, but the mechanism it's using (virtual environments) is not a uv invention.

uv does the Python ecosystem better than any other tool, but it's still the standard Python ecosystem as defined in the relevant PEPs.

replies(1): >>44359719 #
7. 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 #
8. pityJuke ◴[23 Jun 25 20:26 UTC] No.44359719{4}[source]▶
Are the lock files standardised, or a uv-specific thing?
replies(1): >>44360091 #
9. nickelpro ◴[23 Jun 25 21:06 UTC] No.44360091{5}[source]▶
uv has both a uv-specific implementation, and support for standard PEP 751 lockfiles
replies(1): >>44379691 #
10. nickelpro ◴[23 Jun 25 21:10 UTC] No.44360151{3}[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 #
11. akoboldfrying ◴[24 Jun 25 00:17 UTC] No.44361572[source]▶
True, but then all software is developed for this reason.
12. lmm ◴[24 Jun 25 01:27 UTC] No.44361997{4}[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 #
13. lmm ◴[24 Jun 25 01:29 UTC] No.44362012[source]▶
Python package management was notoriously awful. The problem wasn't that people were trying to do things better, it was that they weren't; every new Python dependency management tool just repeated the mistakes of all the previous Python dependency management tools. uv is the first one to break the cycle (and it's probably not a coincidence that it's the first one to not be written in Python).
replies(1): >>44366955 #
14. nickelpro ◴[24 Jun 25 02:34 UTC] No.44362387{5}[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 #
15. lmm ◴[24 Jun 25 03:16 UTC] No.44362587{6}[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 #
16. dwattttt ◴[24 Jun 25 05:34 UTC] No.44363104[source]▶
I would say in many cases they were right; the history of Python package management is littered with winners as well as losers.
17. globular-toast ◴[24 Jun 25 06:42 UTC] No.44363448{4}[source]▶
I said you don't have to think about venvs any more. It's great that we have a standard way to implement them, but this is only necessary in the first place because of the way Python is. Now we have a tool that enforces a workflow that creates virtualenvs without you having to know about them and therefore not screwing them up with ad hoc pip installs etc.
18. blitzar ◴[24 Jun 25 07:53 UTC] No.44363822{4}[source]▶
> How do you think uv works?

Dont know, dont care. It thinks about these things not me.

19. dagw ◴[24 Jun 25 10:08 UTC] No.44364533{7}[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.

20. aragilar ◴[24 Jun 25 11:43 UTC] No.44365079{7}[source]▶
uv only exists because of those standards and therefore can make assumptions that earlier tools could not.
21. nonethewiser ◴[24 Jun 25 14:56 UTC] No.44366955[source]▶
Poetry broke the cycle. Unified toolchain, lock file, single configuration file, full dependency graph, dev dependencies. uv is faster which is great but Poetry was a huge step in the right direction and still a good tool.
22. nickelpro ◴[24 Jun 25 18:14 UTC] No.44369065{7}[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.

23. collinmanderson ◴[25 Jun 25 17:16 UTC] No.44379691{6}[source]▶
Worth noting uv-specific implementation has more features than that standard PEP 751 lockfiles, so uv plans to keep using its own implementation by default. https://github.com/astral-sh/uv/issues/12584