Earlier quoted context omitted.
Wherever you fall on that debate (I have my opinions but they are not strongly held), a bigger red flag here for me is the `pip install ...` opener. The fact they later have a `uvx ...` example in the docs just makes defaulting to pip even worse. As that comment mentions: > 5 years ago [...] Python packaging was a big mess. > Today [...] I think Python's packaging story has never been stronger. Poetry, & later Uv, ar…
> Poetry, & later Uv, are essential & invaluable milestones in that revolutionary story; Pip is terrible software & should be left in the past. The comparison to other programs is missing the point of why pip is terrible. For that matter, last I checked Poetry relied on either vendored pip or something very much like it to do the actual package installation. If you like workflows dictated by all-in-one tools, go for…
You've summarised many of pip's internally problems well - there's also the lack of any attempt at proper manifest management. This is partially an ecosystem problem (pre-PEP518), but the tools inform the specs as much as the specs inform the tools.
I think there's also a reasonable argument to be made that uv only does one thing, & that the big problems in this space before was that python required using 3 tools to awkwardly collaborate to get one thing done. That one thing is dependency management: pip to pull them, venv to load them, pyenv to pull & load one of them (the interpreter).