Before uv there was poetry, and before poetry there was pipenv, before pipenv there was virtualenv. I wish people would stop portraying Python tooling completely wrong like that. uv is not the first tool to solve most problems in this space. It may be the best performing though and may be the best overall currently.
I think you’re underselling it. You’ve listed several projects with many thousand man hours in development.
It’s telling that in Python there have been multiple package managers over the years to fix the broken status quo. Typescript/Javascript notwithstanding, in other languages and environments you get the one tool that’s been there for over a decade without competitors.
Very few languages have suffered from the same package manager issues as JS/TS and Python.
Virtual venv existed before uv. So you could still just generate a virtual venv and then use pip to install packages in the local venv. (2007: virtualenv was released as a third-party tool).
You don't want to install all dependencies globally. You only want to cache them globally. Each project should resolve its own dependency tree independently. If the wanted version is already in cache, use that, otherwise download from the repository even if an older / newer version is present in cache (unless the user specifically says to use the cache only). As long as your dependencies are inert (they don't mess with the system just by being present), this will work perfectly fine.
For non-inert packages, such as applications installed via the language's dependency manager, that's a different use case and should be handled differently.
Comments
I'd argue the other extreme is less sane. Pip installs everything system wide and you can't have different versions of the same package without venv.
Even early NPM was much much better than the pre-uv Python situation. (TBH even with uv it still feels hacky at times.)
Before uv there was poetry, and before poetry there was pipenv, before pipenv there was virtualenv. I wish people would stop portraying Python tooling completely wrong like that. uv is not the first tool to solve most problems in this space. It may be the best performing though and may be the best overall currently.
I think you’re underselling it. You’ve listed several projects with many thousand man hours in development.
It’s telling that in Python there have been multiple package managers over the years to fix the broken status quo. Typescript/Javascript notwithstanding, in other languages and environments you get the one tool that’s been there for over a decade without competitors.
Very few languages have suffered from the same package manager issues as JS/TS and Python.
Wouldn't yarn, grunt and gulp fall into this category?
Also, gulp / grunt weren't package managers.
Very few languages have also suffered their popularity
Virtual venv existed before uv. So you could still just generate a virtual venv and then use pip to install packages in the local venv. (2007: virtualenv was released as a third-party tool).
The global repository should support versions obviously.
You don't want to install all dependencies globally. You only want to cache them globally. Each project should resolve its own dependency tree independently. If the wanted version is already in cache, use that, otherwise download from the repository even if an older / newer version is present in cache (unless the user specifically says to use the cache only). As long as your dependencies are inert (they don't mess with the system just by being present), this will work perfectly fine.
For non-inert packages, such as applications installed via the language's dependency manager, that's a different use case and should be handled differently.
These aren't the only two options.
This
does not inherently mean