link to venv python sees a different sys.path

[Dieter Maurer]

Robin Becker wrote at 2020-3-12 09:07 +0000:
>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

Let me try again:

When you start "python", its "site" module extends "sys.path"
to include an appropriate "site-packages".
For this, it uses a heuristic based on the path with which you
have called the interpreter: i.e. it tries to use
dirname(<path_to_the_interpreter>)/../lib/python<python-version>/site-packages
If this does not exist, it falls back to the base interpreter' "site-packages".

This works fine when you do not use symbolic links.
It can work when your symbolic links do not let the heuristic fail.
As you have observed, some kind of symbolic links break it, however.