This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Antony.Lee
Recipients Antony.Lee
Date 2017-06-30.09:02:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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/
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.
Date User Action Args
2017-06-30 09:02:48Antony.Leesetrecipients: + Antony.Lee
2017-06-30 09:02:48Antony.Leesetmessageid: <>
2017-06-30 09:02:48Antony.Leelinkissue30811 messages
2017-06-30 09:02:47Antony.Leecreate