Why else is this discussion getting hundreds of comments?
For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
It comes up again and again, because people don't realize that solutions already exist(ed) and they don't spend the time to figure things out.
I have managed reproducible Python services and software for multiple years now. This was solved already before uv, although uv does it faster and maybe offers a bit more comfort, although I abstract away such tooling using a simple Makefile anyway.
The reason you are having such a bad time getting random Python projects to work out of the box is, because people creating them did not spend the effort to make them reproducible, meaning, that they do not ensure the setup has same versions and checksums of every direct and transitive dependency. This can be facilitated using various tools these days. poetry, uv, and I am sure there are more. People are just clueless and think that a requirements.txt file with a few loose versions slung in is sufficient. It is not, and you end up with not working project setups like in those cases you refer to.
> For any random python tool out there, I had about a 60% chance it would work out of the box.
Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on.
> uv is the first tool in the python ecosystem that has brought that number basically to 100%.
Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip.
> Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).
lol no it hasn't
Why else is this discussion getting hundreds of comments?
For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
It comes up again and again, because people don't realize that solutions already exist(ed) and they don't spend the time to figure things out.
I have managed reproducible Python services and software for multiple years now. This was solved already before uv, although uv does it faster and maybe offers a bit more comfort, although I abstract away such tooling using a simple Makefile anyway.
The reason you are having such a bad time getting random Python projects to work out of the box is, because people creating them did not spend the effort to make them reproducible, meaning, that they do not ensure the setup has same versions and checksums of every direct and transitive dependency. This can be facilitated using various tools these days. poetry, uv, and I am sure there are more. People are just clueless and think that a requirements.txt file with a few loose versions slung in is sufficient. It is not, and you end up with not working project setups like in those cases you refer to.
> For any random python tool out there, I had about a 60% chance it would work out of the box.
Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on.
> uv is the first tool in the python ecosystem that has brought that number basically to 100%.
Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip.
> Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).
The language (actually the standard implementations build system) has. The problem is programs and installations don't use it.
Big gap between essentially solving it and actually.
The pieces actually all existed for sure.
I can even write scripts to make it all happen.
But uv remains as a long overdue universal command line tool for python.