New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
7 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

This comment has been minimized.

Show comment
Hide comment
@mgedmin

mgedmin May 27, 2015

Contributor

#697 should to fix this.

Contributor

mgedmin commented May 27, 2015

#697 should to fix this.

@gotgenes

This comment has been minimized.

Show comment
Hide comment
@gotgenes

gotgenes Jul 30, 2015

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).

gotgenes commented Jul 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@warsaw
Contributor

warsaw commented Jul 31, 2015

Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015

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
@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Oct 2, 2015

Member

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

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

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 added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015

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
@mgedmin

This comment has been minimized.

Show comment
Hide comment
@mgedmin

mgedmin Oct 2, 2015

Contributor

Yes, this fix works for me.

Contributor

mgedmin commented Oct 2, 2015

Yes, this fix works for me.

@nils-werner

This comment has been minimized.

Show comment
Hide comment
@nils-werner

nils-werner Oct 11, 2015

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?

nils-werner commented Oct 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Oct 12, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@nils-werner

nils-werner Oct 13, 2015

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

nils-werner commented Oct 13, 2015

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

Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 17, 2015

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
@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Oct 17, 2015

Member

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.

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.

@ducust

This comment has been minimized.

Show comment
Hide comment
@ducust

ducust May 29, 2017

@gotgenes
Thank you,But!Your solution need to reinstall virtualenv ;

It can be solved perfectly

ducust commented May 29, 2017

@gotgenes
Thank you,But!Your solution need to reinstall virtualenv ;

It can be solved perfectly

@japherwocky

This comment has been minimized.

Show comment
Hide comment
@japherwocky

japherwocky Aug 9, 2017

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

japherwocky commented Aug 9, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment