Log file Viewer
#pypa logs for Wednesday the 28th of October, 2015
[13:03:33] <mgedmin> somehow I managed to break a pip inside virtualenv so that it was unable to upgrade itself
[13:03:47] <mgedmin> "ImportError: cannot import name InsecurePlatformWarning" somewhere deep in _vendor
[13:04:14] <mgedmin> anyway a 'rm -rf venv/lib && virtualenv venv && venv/bin/pip install -U pip' fixed it
[13:05:09] <mgedmin> full traceback if anyone's curious: https://github.com/ManoSeimas/manoseimas.lt/commit/f9e723f07a60e60a22be2b4a50befdcf7ddd7358
[13:07:29] <dstufft> mgedmin: was this a virtualenv created by a recent Debian or Ubuntu installed virtualenv?
[13:09:00] <mgedmin> originally outside vagrant, I think, judging by the symlinks in local/ that point to /home/mg and not /home/vagrant
[13:10:30] <mgedmin> the thing I find most curious is how the traceback doesn't have any paths outside pip's _vendor
[13:11:02] <dstufft> there is black magic in pip's _vendor in the version of virtualenv that iss hipped in ubuntu I think
[13:11:51] <dstufft> where it will attempt to import from outside of _vendor but make it look like it's still in _vendor
[14:30:52] <nedbat> dstufft: thanks for your help last night, i have a very reproducible scenario that helps me understand things better.
[14:31:18] <nedbat> dstufft: i'm looking through the pip issues to see if it's well described already. i notice issues that should be labelled and/or closed, is that something that would be helpful?
[14:32:36] <dstufft> nedbat: yes that is helpful :) If you CC me on them I can label/close them or you can link them or whatever is easiest for you
[17:04:43] <nedbat> I'm confused about pip options: is there a way to say, "if you decide to install a package, always uninstall the existing one first"?
[17:11:13] <nedbat> apollo13: hmm, perhaps, but if you have a "-e" install, and then do a regular install, the -e is left behind.
[17:12:32] <nedbat> xafer: that will re-install everything, even if the version hasn't changed, right?
[17:13:38] <nedbat> xafer: I have a large requirements.txt, and am trying to finally nail down how to get predictable behavior from it.
[17:14:00] <nedbat> xafer: one of the things we're deciding is, "no more -e", but that means changing from -e to regular, which means we'll have lots left behind
[17:15:09] <nedbat> apollo13: yes, it's a bug in pip. I'm wondering what my options are for doing something about it. :)
[17:17:08] <nedbat> xafer, apollo13: I made a reproducible experiment: https://github.com/nedbat/version_dummy/blob/master/experiment.sh (a bit noisy in output, but the last phase is the one we're discussing)
[17:18:30] <apollo13> nedbat: my paste shows it uninstalling the -e before installing the new package
[17:19:09] <nedbat> apollo13: I know. Now we have to figure out why your scenario is different than mine. You have a file and then a pypi-with-version spec. Mine was using two git urls (which is my real-world concern)
[17:19:47] <nedbat> xafer: i tried adding a "regular, then -e" to my experiment, that seems to upgrade properly: it might still have both, but it runs the latest. with "-e then regular", it runs the old code instead.
[18:05:09] <nedbat> xafer: the plot thickens: e-then-regular continues running the old -e code, but regular-then-e is the one that needs two uninstalls to clean things out. ??
[18:36:06] <nedbat> xafer: ah: my e-then-regular scenaio probably didn't actually do the second install.
[19:42:43] <dstufft> wsanchez: I just verified that should resolve the Apple side of the problem. I think with SIP we'll still need to do some work on our side, but that should be perfect
[19:44:24] <dstufft> (I think we'll try to muck around in those paths still, and ultimately fail because permissions, but that's our fault for mucking around in those paths)
[19:44:40] <wsanchez> SIP just means you can't modified the system python, so as long as system modules can be overriden, we should be OK, no?
[19:45:49] <dstufft> wsanchez: pip would try to say, uninstall something from /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python if it detected it needed to upgrade it, but we need to stop doing that (not just for SIP but also for being better behaved citizens) and start defaulting to --user
[19:46:03] <dstufft> and I think /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python is covered under SIP
[19:46:32] <dstufft> but --user will solve that and is a better answer than mucking around with the system files
[19:46:56] <dstufft> and if the changes in that pastebin happen, --user will work (where it previously didn't because sys.path order)
[19:52:37] <nanonyme> dstufft, meh, who uses PATH anymore anyway? The sanest way on Windows to call stuff is py -2 -m foo params or py -3 -m fooo params
[19:53:31] <dstufft> the tl;dr is that we're going to make --user the default, we just need to hammer out exactly what that means
[19:54:08] <ngoldbaum> the most annoying thing to me re: python on 10.11 is that the openssl headers have been removed, so it's not longer possible to build python with ssl unless you install the headers somehow
[19:55:06] <dstufft> If you use homebrew you can just install your own openssl, you don't need to disable it, /usr/local is exempt from SIP
[19:57:10] <ngoldbaum> right, not for me, but for users on our crazy bootstrapped python install script
[19:59:37] <nanonyme> dstufft, FWIW Windows has delay-resolve environment variables so it's enough to have Python installer to do a global PATH=%PATH%:%USERHOME%\.local\scripts or whatever
[19:59:51] <dstufft> tdsmith: it's got to be the single largest deployment of a MAC to a personal computer
[21:30:10] <dstufft> the main difference is whether a user (root or otherwise) can override the policy