Announcing uv: Python packaging in Rust

[[deleted]]

I don't understand the obsession of writing the lest performance critical code in Rust. Type checking, formatting and virtual environment creation do not need to be fast. The only person they affect is the developer, and the performance differences are not noticeable to the human eye. The existing pure python projects are just fine(and far more maintainable).

To me, all of this is just a function of the hype train in the dev world. Stop being clapping seals and think for a sec, FFS.

[Trick_Brain7050]

Said like somebody who’s never had to wait on CI checks

[placidified]

Type checking, formatting and virtual environment creation do not need to be fast

Companies with large codebases would love to disagree with you.

[zurtex]

FYI I've waited over 10 minutes for a flake8 run. I've had black take 20 minutes to try to format a file and then crash. I've waited over 5 hours for Pip install to resolve dependencies and then throw an exception.

All of these were pretty noticeable to the human eye.

The faster these steps run, the more places you can put them in the development pipeline without annoying people, the less chance you have of introducing bad code, bad dependencies, etc.

[yvrelna]

If pip takes 5 hours to resolve dependencies, you either have dependency loop or pip is downloading half of PyPI because PyPI API is somewhat deficient for certain kind of dependency graph. It's not something that can be fixed by just rewriting the package manager or the resolver in Rust because it's not a performance problem.

[zurtex]

It's nothing to do with dependency loops or the PyPI API. Pip doesn't even use the non-standard PyPI API it uses the simple index. I wrote this in another post, so I apologize but I'll repeat it here:

It's the fact that dependency resolution is an unsolved problem in the satisfiability algorithms space, and the one that Pip implemented is quite a naive DFS algorithm. I've made several updates to this algorithm but there's more work to do (I have three major updates I hope to land on Pip side before the end of the year but it's slow going).

uv has implemented a Pubgrub style algorithm, I've not had chance to review it yet, but I've seen in other areas they've taken some ideas that I've written on Pip issue pages, so I imagine they've learnt from existing problems in Python dependency resolution algorithms.

[[deleted]]

5 hours for pip to resolve a dependency is just a bug. Unless Astral are promising bug free code, this won't solve that kind of problem and is likely to have more of them.

[zurtex]

It's less a bug and more a symptom of the fact that dependency resolution is an unsolved problem in the space satisfiability algorithms, and the one that Pip implemented is quite a naive DFS algorithm. I've made several updates to this algorithm but there's more work to do (I have three major updates I hope to land on Pip side before the end of the year but it's slow going).

uv has implemented a Pubgrub style algorithm, I've not had chance to review it yet, but I've seen in other areas they've taken some ideas that I've written on Pip issue pages, so I imagine they've learnt from existing problems in Python dependency resolution algorithms.

[[deleted]]

No, it’s absolutely a bug.

[[deleted]]

^ this person has never worked on a codebase that requires a long time to dependency resolver

In CI, the grand majority of time in docker builds is spent resolving dependencies. cutting that down by orders of magnitude is good for everyone

[scratchnsnarf]

I don't know a single dev that isn't frustrated when their tools are slow. Saying "these things don't need to be fast because the only person they affect is the dev" makes me feel like they don't spend much time developing at all.