Regarding why not your home directory: which version of Foo do you install, the one that Project A needs or the incompatible one that Project B needs?

The brilliant part about venvs is that A and B can have their completely separate mutually incompatible environments.

They have their place. But the default shouldn't force you into a "project" when you want general purpose applicability. Python should work from the shell as readily as it did 20 years ago. Not mysteriously break what used to work with no low-friction replacement.

Python can work from the shell, if you don’t have external dependencies. But once you have external dependencies, with incompatible potential versions, I just don’t see how you could do this with “one environment”.

It does work from the shell.

Why can't we just have something like npm/gradle/maven dependencies? What makes python any different?

A python virtualenv is just a slightly more complicated node_modules. Tools like PDM, Poetry and uv handle them automatically for you to the point where it effectively is the same as npm.

The thing that makes Python different is that it was never designed with any kind of per-project isolation in mind and this is the best way anyone's come up with to hack that behaviour into the language.

For years, pipx did almost all the work that I needed it to do for safely running utility scripts.

uv has replaced that for me, and has replaced most other tools that I used with the (tiny amount of) Python that I write for production.

> Not when I want to have installable utility scripts usable from all my shells at any time or location.

Can't you just have the thing on your PATH be a wrapper that invokes the tool via its venv?

That's what `uv tool install` does: it creates the wrapper and puts a symlink to it into ~/.local/bin (which you can add to PATH with `uv tool update-shell` if you don't want to do it manually). I don't recall pip doing anything helpful here; I think it still leaves it up to the end user to either add the venv's bin directory to their PATH or create the wrapper and put it somewhere already on the PATH. So it's a reasonable complaint that `pip install` has become less useful now that it resists installing tools outside of a venv but still lacks the replacement feature (which third party tools like uv and pipx do provide).