On 12/03/2020 09:19, Dieter Maurer wrote:
........
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.
Ok I see what you are getting at. However, this sort of defeats the purpose of virtual environments for my case ie when
I want many different versions of python all in one place to use for testing. It's fairly clear that links to links to
links make it quite hard to decide where the real environment is. However, since the virtual environment does have a
lib parallel to the bin it ought not to be impossible.
I can continue to use the 'legacy' version of virtualenv, but it seems as though the latest virtualenv (20.0.8) has
changed something and its linked python now has the same behaviour as the venv version even when the --copies option is
used.
--
Robin Becker
--
https://mail.python.org/mailman/listinfo/python-list
