Alan Gauld via Python-list writes:
On 18/05/2024 19:12, Piergiorgio Sartor via Python-list wrote:
So venvs make managing all that pretty convenient. Dunno why everybody's >> so down on venvs...
Not so much down on them, they are just one extra step that's
mostly not needed(in my use case)
Years ago, I used to have trouble with pip install --user on Debian -- sometimes things would end up under .local, sometimes in other places that I've forgotten. So I reluctantly started using venvs.
And you know, they work fine. I have one master venv that I created with python3 -m venv --system-site-packages ~/pythonenv/envname
and I activate that automatically when I log in, so when I need to install anything that Debian doesn't package, I just pip install it (no --user or --break-system-packages needed) and it installs to that venv.
Every so often I need to regenerate it (like when Debian updates the system Python version) but that's easy to do: I don't try to duplicate what's installed there, I just delete the old venv, create a new one and then pip install packages as needed.
I have a few special venvs (without --system-site-packages) for specific purposes, but most of the time I'm just using my default venv and it's all pretty transparent and automatic.
I know this isn't the usual pythonista model of "you should have a zillion different venvs, one for each program you use, and never use system Python packages", but it works well for me: my pip installed packages are all in a predictable place, and I get
security updates for all the software Debian *does* package. That's my biggest beef with pip, the lack of an easy way to update everything at once, and it's the reason I prefer Debian packages when available.
...Akkana
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)