Skip to content
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

Avoid sys.path pollution when switching interpreters #672

Closed
wants to merge 2 commits into from

Conversation

mgedmin
Copy link

@mgedmin mgedmin commented Dec 2, 2014

Fixes #671

@mgedmin
Copy link
Author

mgedmin commented Dec 2, 2014

I was too hasty in submitting this. It doesn't work, and I can't figure out why:

$ rm -rf /tmp/py34; virtualenv -p python3.4 /tmp/py34
Running virtualenv with interpreter /usr/bin/python3.4
Using base prefix '/usr'
New python executable in /tmp/py34/bin/python3.4
Also creating executable in /tmp/py34/bin/python
ERROR: The executable /tmp/py34/bin/python3.4 is not functioning
ERROR: It thinks sys.prefix is '/usr' (should be '/tmp/py34')
ERROR: virtualenv is not compatible with this system or executable

(My earlier tests were without the rm -rf step, and my patched virtualenv succeeded in updating an existing virtualenv in-place. But it can't create new virtualenvs.)

@mgedmin
Copy link
Author

mgedmin commented Dec 2, 2014

Actually... the develop branch of virtualenv cannot create virtualenvs even without my patch. The error is the same. (But that might've been caused by my accidentally using pip install . on the patched version and pip install -e . on the unpatched one.)

@mgedmin
Copy link
Author

mgedmin commented Dec 2, 2014

Filed #673 for the problem I'm seeing with the develop branch. Unfortunately it means I've no way of testing if this PR fixes the bug it's supposed to fix.

@mgedmin
Copy link
Author

mgedmin commented Dec 2, 2014

I've tested this now and can say that it fixes both #671 and #673 for me.

@mgedmin
Copy link
Author

mgedmin commented Dec 22, 2014

An alternative fix was merged (#674) so I'm closing this one.

@mgedmin mgedmin closed this Dec 22, 2014
@ionelmc
Copy link

ionelmc commented Jan 4, 2015

Can we re-open this? #674 was reverted, #671 still reproduces.

@dstufft dstufft reopened this Jan 4, 2015
@dstufft dstufft mentioned this pull request Jan 5, 2015
5 tasks
@Ivoz Ivoz force-pushed the develop branch 2 times, most recently from d33e617 to 1682ed6 Compare September 20, 2015 16:57
@BrownTruck
Copy link

Hello!

As part of an effort to ease the contribution process and adopt a more standard workflow pip has switched to doing development on the master branch. However, this Pull Request was made against the develop branch so it will need to be resubmitted against master. Unfortunately, this pull request does not cleanly merge against the current master branch.

If you do nothing, this Pull Request will be automatically closed by @BrownTruck since it cannot be merged.

If this pull request is still valid, please rebase it against master (or merge master into it) and resubmit it against the master branch, closing and referencing the original Pull Request.

If you choose to rebase/merge and resubmit this Pull Request, here is an example message that you can copy and paste:

Fixes #671

---

*This was migrated from pypa/virtualenv#672 to reparent it to the ``master`` branch. Please see original pull request for any previous discussion.*

@BrownTruck
Copy link

This Pull Request was closed because it cannot be automatically reparented to the master branch and it appears to have bit rotted.

Please feel free to re-open it or re-submit it if it is still valid and you have rebased it onto master or merged master into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants