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

Tzu-ping Chung added the comment: Unfortunately it is not a viable solution. If you run the virtualenv python without activation, e.g. virtualenv --python=python3.7 foo foo/bin/python -m venv bar The VIRTUAL_ENV environment variable wouldn’t be set in this situation, but the created

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

Ilya Kulakov added the comment: Also hit this issue while trying to run venv on Travis. Perhaps venv should detect if it's running under virtualenv (e.g. the VIRTUAL_ENV env is present) and issue a warning? -- nosy: +Kentzo ___ Python tracker

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

Vinay Sajip added the comment: I'm closing this, as it's not a bug in the venv module. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

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

Change by Josh Holland : -- nosy: +anowlcalledjosh ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Tzu-ping Chung 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

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

cosven added the comment: It is actually a bug in virtualenv instead of venv. > the outer environment's pip leaks into the inner environment; This is true, but why? In short, the inner-env python binary use `outer-env/` directory as its `prefix` direcotry, but the

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

Tzu-ping Chung added the comment: Plot twist: the workaround does not work on Windows. $ cd SOMEDIR ; Placeholder for a valid directory. $ virtualenv env1 ... $ env\Scripts\python.exe Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64

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

Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker ___ ___

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

Tzu-ping Chung added the comment: Would it be possible for venv to do this automatically? Instead of using sys.executable, use import sysconfig dirname, exename = sysconfig.get_config_vars('BINDIR', 'BUILDPYTHON') to populate values in the context? --

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

Vinay Sajip added the comment: > I guess it's reasonable, I'll see whether we can use the workaround you > proposed. OK, please post your findings here. > (Could a fix on virtualenv's side help?) Probably not, as it's not behaving unexpectedly. It might be worth

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

Antony Lee added the comment: I guess it's reasonable, I'll see whether we can use the workaround you proposed. (Could a fix on virtualenv's side help?) Thanks for the explanations. -- ___ Python tracker

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

Vinay Sajip added the comment: Is it OK if I close this? It's not really a bug, nor a case that's been designed for (a stdlib module supporting specific external packages is very unusual - pip support via ensurepip is perhaps the one exception I can think of). Given

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

Vinay Sajip added the comment: > I don't understand why things would be different when nesting? Specifically because venv keeps "a pointer" to the Python environment it was created from. Usually that's a system Python. If a venv ("inner") is created from a

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

Antony Lee added the comment: > venv, on the other hand, doesn't, but keeps a reference to its original > Python environment. That is, I think, the reason for the difference in > behaviour. But for example, using the system Python to create a venv (no nesting),

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

Vinay Sajip added the comment: The problem for venv is that it's tied to the running interpreter, which is (in the case you mention) the one from the outer virtualenv. Unlike virtualenv, venv does not provide a mechanism to restart itself with a different Python

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

Antony Lee added the comment: Travis uses virtualenvs as toplevel containers for running CI. Some projects need (or would like to) set up venvs as part of their test suites. On example is https://github.com/airspeed-velocity/asv, which profiles a project's speed

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

Vinay Sajip added the comment: Can you explain why virtualenv and venv need to be mixed in this way, other than as an academic exercise? If you use -m venv for both inner and outer venvs, then it seems to work as expected. I'm planning to close this as "not a bug"

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

Change by Berker Peksag : -- nosy: +vinay.sajip ___ Python tracker ___ ___

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

Antony Lee added the comment: Sorry, that was a sloppy report. This is a better repro: $ export PIP_CONFIG_FILE=/dev/null # just to be sure python -mvirtualenv outer-env # using /usr/bin/python(3) source outer-env/bin/activate python -mvenv inner-env # using outer-env's python source

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

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