6 ms·

> Share them between projects like every sane package manager. I'd argue the other extreme is less sane. Pip installs everything system wide and you can't have

by matsz 12d ago

> Share them between projects like every sane package manager. 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.)

brabel 12d ago
The global repository should support versions obviously.
diversen7 12d ago
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).
zelphirkalt 12d ago
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.
- dlisboa 12d ago
  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.
  - no_wizard 12d ago
    Very few languages have also suffered their popularity
  - 0x20cowboy 11d ago
    Wouldn't yarn, grunt and gulp fall into this category?
    - c-hendricks 11d ago
      > Typescript/Javascript notwithstanding Also, gulp / grunt weren't package managers.
steveklabnik 12d ago
> the other extreme These aren't the only two options. This > Pip installs everything system wide does not inherently mean > you can't have different versions of the same package
Lvl999Noob 11d ago
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.

by matsz 12d ago

brabel 12d ago

The global repository should support versions obviously.

diversen7 12d ago

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).

zelphirkalt 12d ago

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.

dlisboa 12d ago
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.
- no_wizard 12d ago
  Very few languages have also suffered their popularity
- 0x20cowboy 11d ago
  Wouldn't yarn, grunt and gulp fall into this category?
  - c-hendricks 11d ago
    > Typescript/Javascript notwithstanding Also, gulp / grunt weren't package managers.

steveklabnik 12d ago

> the other extreme These aren't the only two options. This > Pip installs everything system wide does not inherently mean > you can't have different versions of the same package

Lvl999Noob 11d ago

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.