[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Tzu-ping Chung]

Tzu-ping Chung <uranusjr at gmail.com> added the comment:

@cosven you are correct! I made some additional observation while working on adding venv support to pew, in this thread: https://github.com/berdario/pew/pull/173. I’ll try to summarise below.

The root problem is indeed virtualenv’s custom site module, but even then it is possible for venv (or any tool built around it) to know where the “original” Python is, since virtualenv stores the old sys.prefix in sys.real_prefix. Unfortunately, however, this is not as useful as it seems. What we really want in this situation is sys.exec_prefix, which may or may not be the same as sys.prefix. I did manage to cobble together a hack, but it is by no means bullet-proof.

To actually deal with this problem, we will need to amend the site module provided by virtualenv, as you mentioned. But this still can’t “solve” it. Since the site module is vendored in the produced virtualenv, existing virtualenvs will stay broken even after we managed to upgrade the virtualenv installations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________