link to venv python sees a different sys.path

[Robin Becker]

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 at 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