Re: politics. Note that sometimes forks and competitors are so successful, they make it possible for the upstream to "unblock" by virtue of convincing them to adjust their vision. For Node.JS, consider io.js and Yarn in particular.
What are the trade-offs?
As a result the full feature set of pip isn’t supported yet, but since it’s totally interoperable with your regular venv that’s not much of an issue (you can always fall back to pip).
I’ve been playing with it for a month and I can’t imagine going back to vanilla pip.
https://github.com/astral-sh/uv/blob/main/PIP_COMPATIBILITY....
Stop talking about fancy pies, you don’t need it even if it smells nice. What you actually need is to eat healthy and nutritious foods.
Is it really a drop-in replacement for pip? If it's so that's great, then why not also officially replace pip?
For things like dependency resolution, where you're doing a lot of heavy CPU operations, there is a lot of room for optimization in lower level languages.
A compiler bug could put a bug in the compiler and propagate itself indefinitely.
An implementation in some other languages that has an implementation in C means you could theoretically start from ASM and rebuild.
Why do you ask?
I guess the answer for now is "they don't".
Even then, I'm not sure how it would take 1.5 hours even on pen and paper.
Plain pip doesn't really have a lockfile. You can generate a freeze file, but that's something different in practice.
I haven't really been in the Python ecosystem in several years, but my surprise was mostly how there was no mention of Poetry or pipenv. Didn't they address that need before? Are they already out of favor?
uv looks like a good and fast replacement for pip or venv-update but those only take a fraction of a second to run (on a noop, my main use case) so I personally haven't seen where uv would fit in my workflow yet. Maybe building in containers from scratch each time, though again pip is performant enough for me when not doing the hard work of dependency resolution, and for some reason it's not cached.
I am not sure why dependency resolution outside of dev or build systems would be done. But maybe I have escaped the loop.
Getting to a consensus is hard work. They have a vision for how Python packaging and tooling could be better (I assume cargo-like), and a roadmap for improving that. They could have tried to convince the pip maintainers their roadmap was best, but with large fragmented communities like Python it is impossible to reason about how the community will receive changes to tooling. It’s better to build something and get feedback to prove the hypothesis.
The choice of Rust is just because they like the developer ergonomics in that language (I suspect a big reason is that they wanted to ship a single binary independent of any Python env). CPython is written in C because… Guido started to write it in C.
Many comments here don’t understand that their competitors are actually NOT just pip but the conda ecosystem including micromamba (written in C++) which does not attempt to maintain pip interop at all. Conda realized that there are millions of Python programmers who are not developers and could not debug a GCC error message when pip installing scipy.
There are thousands of Python packages that are basically tested on whatever version of Python and libraries the author had installed at the time they wrote it, and literally millions of Github issues that are something like “this doesn’t work because I installed version Y of package X and package Z requires < Y” all vaguely for solveable reasons. Many of these include C/C++ code that builds via custom setup.py scripts.
If you haven’t lost days of work to solving stupid dependency issues in Python I’m not sure you can relate.
