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

Closed
mgedmin opened this Issue May 27, 2015 · 9 comments

Projects

None yet

5 participants

@mgedmin
Contributor
mgedmin commented May 27, 2015

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
Contributor
mgedmin commented May 27, 2015

#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
Contributor
warsaw commented Jul 31, 2015
@Ivoz Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015
@Ivoz Ivoz Remove file's directory from sys.path ASAP
This is needed to particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix #779, #774, #763
8925870
@Ivoz
Member
Ivoz commented Oct 2, 2015

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

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

@Ivoz Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015
@Ivoz Ivoz Remove file's directory from sys.path ASAP
This is needed to particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix #779, #774, #763
832c515
@mgedmin
Contributor
mgedmin commented Oct 2, 2015

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
Member
Ivoz commented Oct 12, 2015

@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 Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 17, 2015
@Ivoz @Ivoz Ivoz + Ivoz Remove file's directory from sys.path ASAP
This is needed particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix #779, #774, #763
348f80c
@Ivoz
Member
Ivoz commented Oct 17, 2015

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.

@Ivoz Ivoz closed this Oct 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment