On 4/17/2025 4:58 AM, Roel Schroeven via Python-list wrote:
Op 15/04/2025 om 20:31 schreef Mats Wichmann via Python-list:
To be clear: you do not have to activate a virtualenv to use *Python*
from it. If you just call the python by the path it's in, it figures
everything out (and sets some variables you can query vi sysconfig if
you have reason to actually need those details (look for installation
schemes).
What activating gives you is some path fiddling, and some prompt
fiddling (although the prompt fiddling keeps saying it's deprecated).
The latter is a visual clue; the former means you can also find
*other* commands installed in the virtualenv - including pip.
/path/to/virtualenv//bin/python -m pip install ... will work whether
you activated or not.
pip install ... finds the first command in your PATH named pip, which
may or may not be the one in the virtualenv, *unless* you've activated
it, because that's the only way the virtualenv bin directory ends up
early in your path.
Or you can cd to the venv directory and it will be first on the pythonpath.
And the pip command that is found and run will use it's own settings
regarding where to install packages, even if you activated a virtualenv.
For example, you can't use /usr/bin/pip to install something in a
virtualenv.
pip detects if you are running in a venv and changes its behavior to match.
To install something in a virtualenv, you need to use the
pip in that virtualenv (either by first activating that venv, or by
running something like venv/bin/pip, or venv). (Of course to do that pip
needs to be installed in that venv. That might or might not be the case
depending on how the venv was created.)
I kinda get the feeling that something like that is going on here.
IMHO pip should always be run as a module, e.g., python3 -m pip. This
way you always get the same pip and environment as the python executable
that is being used.
--
https://mail.python.org/mailman/listinfo/python-list
