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.