Personally, I have avoided all this mess the last couple years by using conda (miniconda install). It does a nice job of keeping entirely separate from the system ( or any other) python, and it can manage non-python libs as well, so you don't need Brew. And it has environments that are like virtualenv, but with the C libs isolated as well.
Between the default channel, conda-forge, and pip for pure python packages, there is a lot available. If we were to add s PyObjC build to conda-forge, the full stack should "just work". And conda forge has s CI system set up to auto build for various python versions.... http://conda-forge.github.io/#add_recipe - CHB > >>>>>> 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 > >
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG