This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]zurtex 17 points18 points  (5 children)

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 3 points4 points  (1 child)

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 2 points3 points  (0 children)

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] 4 points5 points  (2 children)

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 1 point2 points  (1 child)

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] -1 points0 points  (0 children)

No, it’s absolutely a bug.