On 11/03/2020 17:24, Dieter Maurer wrote:
Robin Becker wrote at 2020-3-11 15:26 +0000:
I'm trying to understand why python 3.8.2 venv behaves differently when it is
executed va a link
Make the env
rptlab@everest:~/code/hg-repos
$ python38 -mvenv __py__/382v
...........
so the linked version of the venv python sees the base python site packages and
not the expected venv site-packages.
I guess (!) that it is using the path to the interpreter program
in order to locate the venv's "site-packages" and falls back to
the system's when this is not possible.
If my guess is correct, then some links will not work.
But, you should be able to use links which find
"site-packages" via "<interpreter path>/../lib/python<version>/site-packages".
Not sure I understand exactly what you are getting at, but a workaround is
presumably feasible in any particular script.
The documentation says
"You don’t specifically need to activate an environment; activation just prepends the virtual environment’s binary
directory to your path, so that “python” invokes the virtual environment’s Python interpreter and you can run installed
scripts without having to use their full path. However, all scripts installed in a virtual environment should be
runnable without activating it, and run with the virtual environment’s Python automatically."
I am not running an installed script, but the actual python, however with venv
this is just a link to the base python.
It seems as though the above doesn't apply to the python itself which seems kind of dumb. A quick check reveals that the
documentation later which says
"When a virtual environment is active (i.e., the virtual environment’s Python interpreter is running), the attributes
sys.prefix and sys.exec_prefix point to the base directory of the virtual environment, whereas sys.base_prefix and
sys.base_exec_prefix point to the non-virtual environment Python installation which was used to create the virtual
environment. If a virtual environment is not active, then sys.prefix is the same as sys.base_prefix and sys.exec_prefix
is the same as sys.base_exec_prefix (they all point to a non-virtual environment Python installation)."
is wrong as if you invoke the env/bin/python directly it does change the sys_exec prefix even though the virtual
environment is not 'active'.
$ __py__/382v/bin/python -c"import sys;print(sys.exec_prefix)"
/home/rptlab/code/hg-repos/__py__/382v
whereas that's not the case when invoked via a link
$ bin/python382v -c"import sys;print(sys.exec_prefix)"
/home/rptlab/bin/../LOCAL/382
I guess the problem is that the venv python itself is just a link to the base python whereas the virtualenv pythons are
actual copies of base so presumably know where they live.
I guess I'll continue to use an older mechanism that works for me.
--
Robin Becker
--
https://mail.python.org/mailman/listinfo/python-list
