[Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Christopher Barker]

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 at python.org
>
> https://mail.python.org/mailman/listinfo/pythonmac-sig
>
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161213/c4ad1dbf/attachment-0001.html>