When trying to create a new virtual environment using Python 3.5's venv package from a virtual environment created by the popular 3rd-party virtualenv  package, I get a segfault.

Nested virtual environments work fine both with venv and virtualenv, but using one inside the other doesn't work.  This suggests a subtle incompatibility between the two implementations.

I'm not sure whether compatibility between the implementations is a goal or not at the moment, but there is extensive tooling that uses the 3rd party virtualenv implementation.  For example, I run tests with Tox, which uses virtualenv.  I cannot test any package that uses the standard venv because everything crashes.  As a result of this, I will avoid moving to the standard implementation.

I put up some sample scripts up on GitHub to show how to reproduce the issue.  I hope they can help explain the issue.

https://github.com/AndreLouisCaron/nested-venv-bug

Cheers,

André

By design, the stdlib venv functionality expects to work from an installed Python. However, the Python in a virtualenv venv is not an installed Python - it copies some files from the Python it was installed from and does various other hacks in order to work (I'm not using 'hack' as a pejorative here - it's just what virtualenv has to do).

Thus, you cannot use venv to create an environment from a virtualenv venv's Python. For this to work seamlessly, there would probably need to be coupling between  venv and virtualenv - virtualenv has potentially to be updated with additional hacks every time there is a new Python release, in order to keep working.

It doesn't make sense to couple the stdlib closely with a third-party package. Does it work the other way around? I realise this doesn't help you with tox, and of course tox has to use virtualenv because of supporting older versions of Python ...