virtualenv's develop branch fails to create virtualenvs with a different Python interpreter #673
Comments
|
Reverting commit dde220e fixes this for me. |
|
The irony is that dde220e was supposed to fix the same issue as this one, only in a different way. Pinging @nvie, @saulshanabrook: can you test if this PR doesn't regress your test case (#625)? |
|
Apologies, "this PR" is #672. I meant to post the comment there, not here. Too many open tabs! |
|
The funny thing is that I cannot reproduce the behaviour you mention: $ git clone -b develop https://github.com/pypa/virtualenv
$ cd virtualenv
$ python2.7 virtualenv.py -p python3.4 /tmp/py34
Running virtualenv with interpreter /Users/nvie/.pythonz/pythons/CPython-3.4.2/bin/python3.4
Using base prefix '/Users/nvie/.pythonz/pythons/CPython-3.4.2'
New python executable in /tmp/py34/bin/python3.4
Also creating executable in /tmp/py34/bin/python
Installing setuptools, pip...done.
$ /tmp/py34/bin/python -c 'import sys; print(sys.version_info); print(sys.prefix)'
sys.version_info(major=3, minor=4, micro=2, releaselevel='final', serial=0)
/tmp/py34 |
|
I've tried Python versions 2.6, 2.7, 3.2, 3.3, 3.4, but none of them pose this problem. They all work. |
|
I'm on Ubuntu 14.10. |
|
As opposed to |
|
I suspect what happens here is that My sys.path looks like this: and if I run I'm curious to know why virtualenv doesn't fail for you. |
|
Is |
Ohhh. I wasn't even aware this was happening when I added my patch. Therefore I might indeed have broken something. Removing it at the top level is required to make sure the following imports works as expected. I think we can safely remove the sys.path modification from the |
|
Here's the patch that I tested on top of current develop (commit b7e489f): diff --git a/virtualenv.py b/virtualenv.py
index 2f43427..dd23ff3 100755
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -1113,8 +1113,8 @@ def copy_required_modules(dst_prefix, symlink):
# virtualenv.py is installed under (which might lead to py2/py3
# incompatibility issues)
_prev_sys_path = sys.path
- if os.environ.get('VIRTUALENV_INTERPRETER_RUNNING'):
- sys.path = sys.path[1:]
+## if os.environ.get('VIRTUALENV_INTERPRETER_RUNNING'):
+## sys.path = sys.path[1:]
try:
for modname in REQUIRED_MODULES:
if modname in sys.builtin_module_names:With it the following works: but #671 remains a problem for me. Digging deeper, the My patch in #672 fixes both this bug and #671. I ike it conceptually (the wrong Python's site-packages never get a chance to show up in sys.path) but dislike the implementation (the one-liner that exec()s the contents of a script is grotty). |
|
I've given the Have you tried simply moving the |
|
Yes, moving the |
Fixes pypa#671, pypa#673. base64 should be imported *after* sys.path manipulation -- not doing this causes pypa#671. sys.path is fixed up at the top level (since commit dde220e), doing it again in copy_required_modules() breaks things -- this is pypa#673. This makes the try/finally to restore the old sys.path unnecessary, which produces the gnarly diff :/
|
So the complete fix then boils down to (1) moving the |
|
This should be fixed by the merge of #674 now. |
|
This one also regressed when #674 was reverted. |
|
Actually never mind, I cannot reproduce with 12.0.5. |
Steps to reproduce:
The error is
I get the same error if I use
-p python2.6, or-p python3.3, or-p python3.2, or-p python3.1.I don't get the error if I use
-p python2.7or-p pypy.I don't get the error if I switch to the
masterbranch and use-p python3.4.The text was updated successfully, but these errors were encountered: