-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
invert site-packages behavior #178
Conversation
… --use-site-packages flag
Hi @mcdonc - I'm certainly willing to consider this; it's been previously requested. It would be helpful to know what sort of "conflicting package" problems users tend to have, in your experience? Generally packages in the virtualenv should simply override global ones, and there shouldn't be a problem. So I'm wondering if your experiences shed light on other bugs that might be fixable, regardless of whether we invert the default as you suggest. |
I've asked on the mailing list about preferences on this: http://groups.google.com/group/python-virtualenv/browse_frm/thread/57e11efac3743149 |
One concrete issue to start with is on MacOSX. "zope.interface" is present on some path in the system interpreter on most versions of MacOS. It's an older version of this package, apparently used by Apple system packages. When someone installs virtualenv into the system interpreter on such a system, and subsequently creates a virtual environment without "--no-site-packages", installation of Pyramid using the virtualenv bin/easy_install or bin/pip fails. I can't, at the moment, describe exactly how it fails because I don't have a Mac on me. But the general symptom "cant install Pyramid" is reported to us two or threee times a week; when we ask the reporter to use --no-site-packages, it works for them. That issue aside, I think the supplied patch is a better default. AFAICT, virtualenv is designed to provide an isolated environment, and with the current set of defaults, it just doesn't. This puts folks in a position where they think they're troubleshooting an isolated system, but they aren't. |
While I'm +1 on changing the default behavior here, the zope.interface issue is actually a bug in pip with how it resolves version requirements in packages. I'll explain my version of what's going on without looking at pip's source.
Users are able to successfully run
During the install they saw:
Explanation:
It would appear as if pip is accepting the first "pin" it finds, and ignoring the z.c requirement of 3.8.0, causing issues later. This is not an issue with easy_install, which actually fails while doing
In both cases it's possible to upgrade |
Thanks for the extended analysis of the zope.interface situation. I believe that's bug pypa/pip#174 - knowing that it's biting people regularly (and that easy_install handles it better, which I didn't realize) definitely ups the priority level on getting that fixed. Given the feedback on the mailing list thread, I'm not seeing any reason we shouldn't make this change. I may wait a few days for @jezdez to get back from vacation so I can confirm with him. |
Yeah, +1 from me. |
Invert site-packages behavior. Thanks, Chris McDonough.
Merged - thanks @mcdonc. |
Virtualenv is used, primarily, to create an isolated packaging environment. The current default use-site-packages behavior is suboptimal for this purpose. New users (and some experienced users) invariably fail to pass the flag even when instructions to do so are in blinking red text in a 72 point font, and they wind up in a place where they have conflicting global and virtualenv packages. This is, by far, the most common support issue I've experienced in regards to instructing other people to use virtualev.
It would make a lot more sense if virtualenv defaulted to
--no-site-packages
behavior. This patch does that, and adds a--use-site-packages
flag to get the old behavior back.