> On Oct 7, 2016, at 1:36 AM, Andrew Jaffe <a.h.ja...@gmail.com> wrote: > > On 06/10/2016 20:26, Glyph Lefkowitz wrote: >>> On Oct 6, 2016, at 2:56 AM, Andrew Jaffe wrote: >>> On 17/09/2016 18:59, Glyph Lefkowitz wrote: >>>>> On Sep 17, 2016, at 9:27 AM, Ned Deily wrote: >>>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe wrote: >>>>>>> >>>>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>>>> total 0 >>>>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>>>> >>>>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>>>> prediction about setuptools' behavior :) >>>>> >>>>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>>>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>>>> unfortunately, due to https://bugs.python.org/issue4865, the >>>>> site-packages directory for the system Python 2.7 is included in >>>>> sys.path along with the non-system framework Python site-packages. >>>> >>> So, a little more data: >>> >>> If you rename or remove /Library/Python/2.7/site-packages/Extras.pth >>> then pip2 works. >> >> What do you mean by "works"? Your original error is pip refusing to >> upgrade pyObjC because to upgrade pyObjC it has to delete the old >> version, and pyObjC is part of the operating system, and it can't delete >> the installed version. This is correct; the error reporting could be >> nicer, but pip is not broken. Don't mess with files in /System. >> >> The suggestion to use virtualenv isn't really optional. If you really, >> really want things to be importable by a bare 'python', not inside a >> venv, `pip install --user` is another option you might have. >> >>> *However*, lots of other stuff breaks -- anything that uses Apple's >>> python and relies on access to pyobjc and the frameworks (e.g., >>> TextMate's latex package). >> >> Yep, that's expected behavior. This is exactly why Apple is making it >> increasingly difficult to screw up /System. Apps can, should, and do >> rely upon the libraries installed on the system. >> >>> What I don't understand is: what changed from Yosemite? This file did >>> not exist before Sierra, but there were no problems with (Apple) >>> python accessing these packages. >> >> Do you mean from El Capitan? > > Yes, sorry. > >> This file previously existed in a different location, and (while the >> particulars stubbornly refuse to stick to memory for me, for some >> reason) this new location is the one generally preferred by the python >> packaging maintainers. >> >>> (Or is there something unique in my setup that is causing this? I kind >>> of doubt it, but it's possible...) >>> >>> Does anyone have any insight? >> >> If you really, really, really want to do this in such a way that /System >> stuff is only present for /System's python and not for python.org >> <http://python.org>'s, you can take advantage of the 'import' hack >> <https://docs.python.org/2/library/site.html>, and >> rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_ >> add those entries to sys.path, checking sys.executable or some other >> fingerprint. >> >> But: don't. Given that system python and python.org <http://python.org> >> python share /Library and ~/Library, they're not /really/ distinct >> environments, and things installed into one will show up in the other, >> so excluding the /System directories on one but not the other will just >> cause other, more confusing issues. >> >> In conclusion: just use virtualenv. This is not a problem that should >> be fixed. > > I agree that this would solve all of the problems, at the cost of some minor > startup pain. > > But one nice thing about the python.org builds is that, for the last few > releases, they just worked out of the box, where by "worked" I mean that (as > far as I can tell) the system Python saw its own packages, and the python.org > build saw its own packages, and (python.org) pip didn't seem to care about > the system files.
Trust me, they didn't just work :). There were numerous potential misconfigurations that dealt with conflicts between system python packages and user-installed packages. Installing stuff into the global environment has always been a bad idea. Some system files would be on the path, some wouldn't, and things installed into one environment would bleed over into the other. > And I suppose I still don't understand exactly why that changed with Sierra, > and whether the change is actually beneficial in any way whatever! (And > whether it could only be fixed by Apple, or whether a change in the > python.org build could do something about it.) I'm not sure as to the exact difference, but my basic understanding is that rather than failing silently and ignoring system-installed stuff, pip now reliably and correctly fails to upgrade system packages that are protected by SIP. > Sorry to keep harping on about it, but I find it hard to believe this is not > a fairly widespread problem! (Well, I found at least one other complaint: > https://jasonkratz.com/2016/09/25/python-2-7-on-the-mac-site-package-weirdness/) The problem is that we're not properly getting the message out about how to set up Python for development; venvs are increasingly graduating from "best practice" to "necessary to function", but I don't think users are getting the message. (Case in point: this thread is still going :).) System packages are for system developers. If you aren't shipping Python.org python itself, or working for apple on OS X, you should not be installing things into /Library or even as a user with *permission* to install things into /Library. -glyph _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
