[kstrauser]

> Third, virtual environments are literally just a place on disk for those dependencies

I had a recent conversation with a colleague. I said how nice it is using uv now. They said they were glad because they hated messing with virtualenvs so much that preferred TypeScript now. I asked them what node_modules is, they paused for a moment, and replied “point taken”.

Uv still uses venvs because it’s the official way Python stores all the project packages in one place. Node/npm, Go/go, and Rust/cargo all do similar things, but I only really here people grousing about Python’s version, which as you say, you can totally ignore and never ever look at.

[zahlman]

From my experience, it seems like a lot of the grousing is from people who don't like the "activation script" workflow and mistakenly think it's mandatory. Though I've also seen aesthetic objections to the environment actually having internal structure rather than just being another `site-packages` folder (okay; and what are the rules for telling Python to use it?)

The very long discussion (https://discuss.python.org/t/pep-582-python-local-packages-d...) of PEP 582 (https://peps.python.org/pep-0582/ ; the "__pypackages__" folder proposal) seems relevant here.

[kstrauser]

I've heard those objections, too. I do get that specific complaint: it's another step you have to do. That said, things like direnv and mise make that disappear. I personally like the activation workflow and how explicit it is, as you're activating that specific venv, or maybe one in a different location if you want to use that instead. I don't like sprinkling "uv run ..." all over the place. But the nice part is that both of those work, and you can pick whichever one you prefer.

It'll be interesting to see how this all plays out with __pypackages__ and friends.

[zahlman]

> But the nice part is that both of those work, and you can pick whichever one you prefer.

Yep. And so does the pyenv approach (which I understand involves permanently adding a relative path to $PATH, wherein the system might place a stub executable that invokes the venv associated with the current working directory).

And so do hand-made subshell-based approaches, etc. etc.

In "development mode" I use my activation-script-based wrappers. When just hacking around I generally just give the path to the venv's python explicitly.

[kstrauser]

I use your "hacking around" method for things like cron jobs, with command lines like:

  * * * * * /path/to/project/.venv/python /path/to/project/foo.py

It's more typing one time, but avoids a whole lot of fragility later.