How are venv’s different from --user installation? Afaik --user also doesnt interfere but packages work well and everywhere.
One can think of a virtualenv as a user install, but in a particular folder. So you can have any number of virtual environments and you can have any of these active simultaneously if you wish—this is often the case when developing in Python when different projects have different requirements/dependencies. If you always did a --user install, you couldn’t have multiple sets of packages with different versions and so on.
Additionally, a user install is “active” by default—you don’t activate and deactivate it. So this can create conflicts with system packages. A virtual env has to be activated and will only be active in that particular shell.
2 Likes
Thanks, well explained.
I think for general users that “just need that python package” (I can think of pyclip for Waydroid) a --user install would fit. But its also available as an RPM which is probably tested to not conflict with system dependencies?
1 Like
pip install - -user is being blocked by pip these days to prevent breaking system installed python scripts.
That is forcing the use of venv in place of --user installs.
I made the transition myself a while ago. I have a .local/tools-venv that I install into and added symlinks from .local/tools-venv/bin tools into my ~/bin.
2 Likes
The problem with pip install --user for “just that one package” is when there is “just one more” package, and they have a dependency in common, but conflicting version bounds. Separate virtualenvs make that not a problem. System-wide packages don’t solve the problem, but they reassign it to the package maintainers and make it not your problem.
You might also be interested in pipx.
2 Likes