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