virtualenv -p python3.5 fails if enum34 is installed alongside it

[mgedmin]

STEPS TO REPRODUCE

Create a virtualenv to install virtualenv to make it very explicit what other packages are sharing site-packages with it:

1. virtualenv -p python2.7 /tmp/py27
2. /tmp/py27/bin/pip install virtualenv enum34

And now that we have a clearly-defined execution environment:

$ /tmp/py27/bin/virtualenv -p python3.5 /tmp/py35
Running virtualenv with interpreter /home/mg/.local/bin/python3.5
Traceback (most recent call last):
  File "/tmp/py27/lib/python2.7/site-packages/enum/__init__.py", line 371, in __getattr__
    return cls._member_map_[name]
KeyError: '_convert'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/py27/local/lib/python2.7/site-packages/virtualenv.py", line 23, in <module>
    import subprocess
  File "/home/mg/python3.5/lib/python3.5/subprocess.py", line 364, in <module>
    import signal
  File "/home/mg/python3.5/lib/python3.5/signal.py", line 8, in <module>
    _IntEnum._convert(
  File "/tmp/py27/lib/python2.7/site-packages/enum/__init__.py", line 373, in __getattr__
    raise AttributeError(name)
AttributeError: _convert

This doesn't fail if I substitute python3.5 with python3.4. It obviously doesn't fail if enum34 is not installed into the Python 2.7 virtualenv.

[mgedmin]

697 should to fix this.

[gotgenes]

Thanks for tracking down this issue! I found I could work around this by running

pip uninstall enum34

first (where pip is for a Python 2.7 version of pip).

[warsaw]

There's also some discussion of this issue over here: https://bitbucket.org/stoneleaf/enum34/issues/5/enum34-incompatible-with-python-35#comment-19462547

[Ivoz]

@mgedmin would appreciate if you could check if above commit solves the issue

https://github.com/Ivoz/virtualenv/archive/early-syspath-removal.zip

[mgedmin]

Yes, this fix works for me.

[nils-werner]

I find it very weird that the inner virtualenv interpreter tries to import from the surrounding environment. It sounds like a source of many headaches... Is this by design?

[Ivoz]

@nils-werner the python interpreter finding modules for a script file's absolute imports in its surrounding directory is by design, yes.

[nils-werner]

But it certainly can't be by design that the interpreter imports from a different interpreters site-packages, right?

[Ivoz]

It's only because we are executing a file that _just so happens_ to be located in site-packages (virtualenv.py). So it's "not a normal" case. I've just pulled #805 which should fix this.

[ducust]

@gotgenes
Thank you，But！Your solution need to reinstall virtualenv ;

It can be solved perfectly

[japherwocky]

Is there any way to work around this if we can't remove enum34?