New submission from Antony Lee: Python 3.6.1, virtualenv 15.1.0 (Arch Linux, distro packages)
``` export PIP_CONFIG_FILE=/dev/null # just to be sure # python -mvirtualenv outer-env # using /usr/bin/python(3) python2 -mvirtualenv outer-env # using /usr/bin/python(3) source outer-env/bin/activate python -mvenv inner-env # using outer-env's python source inner-env/bin/activate python -minspect -d pip ``` The last step outputs ``` Target: pip Origin: /tmp/inner-env/lib/python3.6/site-packages/pip/__init__.py Cached: /tmp/inner-env/lib/python3.6/site-packages/pip/__pycache__/__init__.cpython-36.pyc Loader: <_frozen_importlib_external.SourceFileLoader object at 0x7f27c019c710> Submodule search path: ['/tmp/inner-env/lib/python3.6/site-packages/pip'] ``` i.e., the outer environment's pip leaks into the inner environment; the inner environment does not have its own pip installed. Trying to use that pip from the inner environment (from inner-env, `python -mpip install ...`) results in the package being installed in the outer environment rather than the inner one. Now this may all seem very academic, but for example Travis uses virtualenvs as toplevel containers for their Python projects, so this bug makes it difficult to test, say, projects that set up venvs as part of their workflow. ---------- components: Library (Lib) messages: 297365 nosy: Antony.Lee priority: normal severity: normal status: open title: A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own. versions: Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30811> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
