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

[Christopher Barker]

On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz 
wrote:

>
> On Dec 14, 2016, at 9:44 AM, Chris Barker  wrote:
>
> conda also has a non-framework build of Python -- not sure if that would
> cause any issues with the wheels.
>
>
> I am not up on all the technical specifics, but this suggests to me that
> Conda would be generally unsuitable for use as a Mac native development
> environment, and hence not a Python you'd want to use pyobjc with.
>
> If you don't have a framework build, you don't have an app bundle;
>

in the standard python.org builds, the Framework Build provides an app
bundle. But having python in a Framework is completely orthogonal to the
App BUndle issue.

Yes, you need the executable to be in an app bundle in order to access the
Window manager (and who knows what else), but again, that has nothign to do
with the Framework Build.

unfortunately, the build scripts only have a couple ready-to-go options, so
to get the app bundle executable, you do need the Framework build.

I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's
no good reason for a Framework build at all -- it just seemed like the
Apple-y way to do it at the time, and now we have the legacy.


However, conda has supplied an app bundle version, which you can install
with:

conda install python.app

it supplies a "pythonw" script that bootstraps s python inside a app bundle
and can run GUI apps -- I know it works fine with wxPython, for instance.

Having to use pythonw is a kind of a pain -- and the ned for it was removed
years ago in the Framework builds -- those builds leverage a small
executable that bootstraps into an app bundle -- and works fine as a
"regular" python interpreter as well.

There's no reason we couldn't build that same executable outside a
framework -- someone just need to figure out the build scripts -- which i
was hoping to do last PyCon, but you can only get so much done in a 1-1/2
days of sprinting -- plus I'm no build script expert. At All.


Anyway, it should be easy to see how well the new wheels work with conda --
and/or make a conda recipe -- maybe I'll get to it soon.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Glyph Lefkowitz]

> On Dec 14, 2016, at 9:44 AM, Chris Barker  wrote:
> 
> conda also has a non-framework build of Python -- not sure if that would 
> cause any issues with the wheels.

I am not up on all the technical specifics, but this suggests to me that Conda 
would be generally unsuitable for use as a Mac native development environment, 
and hence not a Python you'd want to use pyobjc with.

If you don't have a framework build, you don't have an app bundle; if you don't 
have an app bundle then many frameworks will fail to initialize, or will start 
behaving in bizarre ways.  APIs like NSUserNotificationCenter will just 
silently do nothing, CoreLocation won't respond... it's always very confusing 
and hard to troubleshoot.

That said, I don't think the framework/non-framework-ness of the build is 
relevant to the ABI; the wheels should work fine just from a "will they link 
and run" perspective.  And many CoreFoundation APIs definitely work without an 
app bundle, so, not completely useless :-).

-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

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

[Chris Barker]

On Tue, Dec 13, 2016 at 11:16 AM, Glyph Lefkowitz 
wrote:

> 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
>
>
> Why would this be necessary?  Can't conda just install the wheels from
> PyPI?
>

Well, maybe -- conda has grown better support for pip lately, so it may
work OK.

Back in the day, mixing conda and pipi got ugly fast, so I far prefer to
make a native conda package for everything.

conda also has a non-framework build of Python -- not sure if that would
cause any issues with the wheels.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Glyph Lefkowitz]

> On Dec 13, 2016, at 8:37 AM, Christopher Barker  wrote:
> 
> 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 
> 
Why would this be necessary?  Can't conda just install the wheels from PyPI?

-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

Re: [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
>
> >> 's, you can take advantage of the 'import' hack
>
> >> , 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  >
>
> >> 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
> 

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

[Ronald Oussoren]

> On 14 Sep 2016, at 00:28, Glyph Lefkowitz  wrote:
> 
> 
>> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe > > wrote:
>> 
>> But this is the framework (non-apple!) build!…
> 
> "framework build" refers to the way that Python is built.  Apple's python, 
> Python.org 's python, and Homebrew's python are all 
> framework builds.  So, to be clear: this is python.org  
> python?
> 
>> And, again: why isn’t everyone seeing this all the time? (And why didn’t I 
>> see it before?)
> 
> There's probably a .pth file somewhere that is stuffing Extras on your 
> sys.path.  easy_install (especially older versions) is notorious for creating 
> such things in ways that are hard to inspect for.  My usual recommendation at 
> this point is to blow away _everything_ in /Library/Python, ~/Library/Python, 
> ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then 
> reinstall from scratch.  (Thanks to SIP you don't need to blow away anything 
> in /System anymore; hooray!)

It should be enough to remove “/Library/Python” from the list of site packages 
in the non-system install of Python, it is added at the end of 
setsitepackages() in site.py. This should be done before running any code 
(particularly the ensurepip tool).  That would remove the directory containing 
the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and 
user provided stuff.   Doing this with the python.org installer requires some 
care, as it will by default run ensurepip during the installation (but this can 
be turned off).

According to issue 28440 /Library/Python/2.7/site-packages will no longer be 
treated as a site-packages directory in a future release of 2.7.

Ronald

> -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

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

[Glyph Lefkowitz]

> On Oct 7, 2016, at 1:36 AM, Andrew Jaffe  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
>> 's, you can take advantage of the 'import' hack
>> , 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 
>> 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 

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

[Glyph Lefkowitz]

> 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:
> 
> Aha!
> 
> $ 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
> 
> Now I wonder how those got there?!
> 
 
 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?

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's, you can take 
advantage of the 'import' hack , 
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 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.

-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

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

[Glyph Lefkowitz]

> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe  wrote:
> 
> Not me. If I understand correctly, Glyph -- who undoubtedly understand the 
> situation better than I do -- still thinks that there's no actual bug here, 
> since we shouldn't be using the framework build this way, but I'm not sure I 
> understand/agree...

To be honest, I'm not 100% sure this is a good idea either; it's just that I 
know Donald Stufft has had a terrible time with Apple system python for several 
years, and he regards this as a positive change.  From my personal perspective, 
there's a good case to be made that a python in /System should just load from 
/System and one in /Library should load only from /Library, similar to the way 
--prefix works on "regular" UNIX.  But, this is what we've got :).

-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

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

[Glyph Lefkowitz]

> On Sep 21, 2016, at 01:52, Andrew Jaffe  wrote:
> 
> That would work, and in fact I don't really need PyObjC (sorry, Ronald!) but 
> I've got my whole setup working with the "global" python.org 
>  framework build, so I am used to that... and the Sierra 
> status quo does seem ugly (and quite possibly is a bug!).

Well, Apple ships certain libraries, and they want them to be on your path.

The nice thing about virtualenv is that, along with pip wheel caching, 
re-creating them is really fast, so you don't have to just do one setup; you 
just make a requirements.txt for each separate environment you want, and 
regularly re-create it, so you know that if you give directions to anyone else, 
your setup will work for them as well.

One bad habit we get into is getting a full-on environment set up on our own 
workstation, and then not knowing exactly what we installed, and therefore what 
we need in order for someone else to build and work on our software.  
Virtualenv helps reduce that problem a bit.

-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

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

[Glyph Lefkowitz]

> 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:
>>> 
>>> Aha!
>>> 
>>> $ 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
>>> 
>>> Now I wonder how those got there?!
>>> 
>> 
>> 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.

Hrm.  I guess everyone I knew on the beta was using homebrew python :(.

I'm surprised that Apple is putting stuff in /Library.  I don't have a Sierra 
box handy - /Library isn't SIP-protected now, is it?

This seems wrong; someone should file a radar (and probably share on 
http://www.openradar.me for further discussion).

-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

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

[Glyph Lefkowitz]

> On Sep 20, 2016, at 10:29 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:
> 
> Aha!
> 
> $ 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
> 
> Now I wonder how those got there?!
> 
 
 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.
>> 
>> Hrm.  I guess everyone I knew on the beta was using homebrew python :(.
>> 
>> I'm surprised that Apple is putting stuff in /Library.  I don't have a 
>> Sierra box handy - /Library isn't SIP-protected now, is it?
> 
> Nope, that's not a problem.
>> 
>> This seems wrong; someone should file a radar (and probably share on 
>> http://www.openradar.me  for further discussion).
> 
> In the meantime, what's the recommended workaround?

Looking back over the thread, my first reply was: "Make a virtualenv and 
install pyobjc there", but I didn't see a direct response to that.  That would 
still be my first choice for a workaround.  Is there some reason that doesn't 
work for you?

-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

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

[Glyph Lefkowitz]

> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe  wrote:
> 
> But this is the framework (non-apple!) build!…

"framework build" refers to the way that Python is built.  Apple's python, 
Python.org's python, and Homebrew's python are all framework builds.  So, to be 
clear: this is python.org python?

> And, again: why isn’t everyone seeing this all the time? (And why didn’t I 
> see it before?)

There's probably a .pth file somewhere that is stuffing Extras on your 
sys.path.  easy_install (especially older versions) is notorious for creating 
such things in ways that are hard to inspect for.  My usual recommendation at 
this point is to blow away _everything_ in /Library/Python, ~/Library/Python, 
~/.local/lib/python*, and /Library/Frameworks/Python.framework and then 
reinstall from scratch.  (Thanks to SIP you don't need to blow away anything in 
/System anymore; hooray!)

-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

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

[Glyph Lefkowitz]

> On Sep 13, 2016, at 12:05 PM, Jack Jansen  wrote:
> 
> I think 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
> is a very old location for storing Python packages. Recently things have been 
> installed in /Library/Python/2.7/site-packages.
> 
> Could it be that you’ve installed pyobjc a couple of OSX releases ago?

This is always worth checking ;).  Particularly if it was a few Setuptools 
releases ago.  Also worth checking: ~/Library/Python.

> And could it be that the OSX upgrade that introduced SIP somehow didn’t clean 
> out user-installed things from /Library/Frameworks before turning off write 
> permission?

SIP locks down /System, not /Library.

> A possible workaround is to turn off SIP (or boot from the recovery 
> partition), record what is in 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
> and then clean it out. Then after a reboot re-install the packages you’re 
> still using.


This should be an _absolute_ last resort, though.  You should be able to clean 
out /Library just fine.  If you have a /Library/Frameworks/Python.framework, 
that's probably Python.org  python, not system python.

-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

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

[Glyph Lefkowitz]

> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe  wrote:
> 
> Aha!
> 
>  $ 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
> 
> Now I wonder how those got there?!
> 

Hah!  Thanks for sharing.  Very satisfying to actually make a *correct* 
prediction about setuptools' behavior :)

-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

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

[Ronald Oussoren]

> On 25 Oct 2016, at 10:36, Andrew Jaffe  wrote:
> 
> On 12/10/2016 21:02, Ronald Oussoren wrote:
> >
> >> On 12 Oct 2016, at 21:09, Glyph Lefkowitz  >> > wrote:
> >>
> >>> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe  >>> > wrote:
> >>>
> >>> Not me. If I understand correctly, Glyph -- who undoubtedly
> >>> understand the situation better than I do -- still thinks that
> >>> there's no actual bug here, since we shouldn't be using the framework
> >>> build this way, but I'm not sure I understand/agree...
> >>
> >> To be honest, I'm not 100% sure this is a good idea either; it's just
> >> that I know Donald Stufft has had a terrible time with Apple system
> >> python for several years, and he regards this as a positive change.
> >>  From my personal perspective, there's a good case to be made that a
> >> python in /System should just load from /System and one in /Library
> >> should load only from /Library, similar to the way --prefix works on
> >> "regular" UNIX.  But, this is what we've got :).
> >
> > I don’t mind if the /System python looks in /Library for stuff that the
> > user installed there, but I do consider it a bug that Apple installs
> > system files in /Library because that affects all installations of
> > Python 2.7.
> >
> > That’s what we get for playing nice with OSX conventions for where to
> > locate files :-(. Luckily this isn’t a problem for Python3 as Apple
> > doesn’t ship that (and I’d be surprised if they ever unless they start
> > shipping Python3 code as part of the OS).
> 
> Well, I did submit a radar, and although I'm not sure how far the NDA 
> extends, I hope I can say that, unfortunately, I got a "behaves as intended" 
> response…

That’s too bad. But I wouldn’t expect this to change anytime soon even if this 
would have been classified as a bug.

Ronald

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

On 12/10/2016 21:02, Ronald Oussoren wrote:
>
>> On 12 Oct 2016, at 21:09, Glyph Lefkowitz > > wrote:
>>
>>> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe >> > wrote:
>>>
>>> Not me. If I understand correctly, Glyph -- who undoubtedly
>>> understand the situation better than I do -- still thinks that
>>> there's no actual bug here, since we shouldn't be using the framework
>>> build this way, but I'm not sure I understand/agree...
>>
>> To be honest, I'm not 100% sure this is a good idea either; it's just
>> that I know Donald Stufft has had a terrible time with Apple system
>> python for several years, and he regards this as a positive change.
>>  From my personal perspective, there's a good case to be made that a
>> python in /System should just load from /System and one in /Library
>> should load only from /Library, similar to the way --prefix works on
>> "regular" UNIX.  But, this is what we've got :).
>
> I don’t mind if the /System python looks in /Library for stuff that the
> user installed there, but I do consider it a bug that Apple installs
> system files in /Library because that affects all installations of
> Python 2.7.
>
> That’s what we get for playing nice with OSX conventions for where to
> locate files :-(. Luckily this isn’t a problem for Python3 as Apple
> doesn’t ship that (and I’d be surprised if they ever unless they start
> shipping Python3 code as part of the OS).

Well, I did submit a radar, and although I'm not sure how far the NDA 
extends, I hope I can say that, unfortunately, I got a "behaves as 
intended" response...


Andrew



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

On 11/10/2016 22:26, Ronald Oussoren wrote:



On 17 Sep 2016, at 19: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:

Aha!

$ 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

Now I wonder how those got there?!



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.


Hrm.  I guess everyone I knew on the beta was using homebrew python :(.

I'm surprised that Apple is putting stuff in /Library.  I don't have a
Sierra box handy - /Library isn't SIP-protected now, is it?

This seems wrong; someone should file a radar (and probably share
on http://www.openradar.me  for further
discussion).


Did someone file a radar for this? Otherwise I can do so.


Not me. If I understand correctly, Glyph -- who undoubtedly understand 
the situation better than I do -- still thinks that there's no actual 
bug here, since we shouldn't be using the framework build this way, but 
I'm not sure I understand/agree...



I can affirm that Extras.pth is now in /Library/Python/2.7 instead of in
a system location. This sucks as bits of the system install now infect
other installs of Python 2.7. One more reason to stop using 2.7 I guess ;-)


Andrew


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

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
's, you can take advantage of the 'import' hack
, 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 
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. 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.)


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/)


Andrew


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

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:

Aha!

$ 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

Now I wonder how those got there?!



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. *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).


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.


(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?

Thanks,

Andrew




___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

On 20/09/2016 20:54, Glyph Lefkowitz wrote:
>> On Sep 20, 2016, at 10:29 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:

>>
>> Aha!
>>
>> $ 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.
>>>
>>> This seems wrong; someone should file a radar (and probably share
>>> on http://www.openradar.me  for further
>>> discussion).
>>
>> In the meantime, what's the recommended workaround?
>
> Looking back over the thread, my first reply was: "Make a virtualenv and
> install pyobjc there", but I didn't see a direct response to that.  That
> would still be my first choice for a workaround.  Is there some reason
> that doesn't work for you?

That would work, and in fact I don't really need PyObjC (sorry, Ronald!) 
but I've got my whole setup working with the "global" python.org 
framework build, so I am used to that... and the Sierra status quo does 
seem ugly (and quite possibly is a bug!).


Andrew

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

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:

Aha!

$ 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

Now I wonder how those got there?!



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.


Hrm.  I guess everyone I knew on the beta was using homebrew python :(.

I'm surprised that Apple is putting stuff in /Library.  I don't have a Sierra 
box handy - /Library isn't SIP-protected now, is it?


Nope, that's not a problem.


This seems wrong; someone should file a radar (and probably share on 
http://www.openradar.me for further discussion).


In the meantime, what's the recommended workaround?

A
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Ned Deily]

On 2016-09-13 19:33, Glyph Lefkowitz wrote:
>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe > > wrote:
>>
>> Aha!
>>
>>  $ 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
>>
>> Now I wonder how those got there?!
>>
> 
> 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.



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

Hi,


> On 13 Sep 2016, at 23:28, Glyph Lefkowitz  wrote:
> 
> 
>> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe  wrote:
>> 
>> But this is the framework (non-apple!) build!…
> 
> "framework build" refers to the way that Python is built.  Apple's python, 
> Python.org's python, and Homebrew's python are all framework builds.  So, to 
> be clear: this is python.org python?
> 

Doh! Yes, sorry, I think I said this way back in the thread: python.org 2.7.12 
(problem doesn’t arise with 3.5.2, also installed). But see this...

>> And, again: why isn’t everyone seeing this all the time? (And why didn’t I 
>> see it before?)
> 
> There's probably a .pth file somewhere that is stuffing Extras on your 
> sys.path.  easy_install (especially older versions) is notorious for creating 
> such things in ways that are hard to inspect for.  My usual recommendation at 
> this point is to blow away _everything_ in /Library/Python, ~/Library/Python, 
> ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then 
> reinstall from scratch.  (Thanks to SIP you don't need to blow away anything 
> in /System anymore; hooray!)

Aha!

  $ 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

Now I wonder how those got there?!

A




> 
> -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

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

[Andrew Jaffe]

OK, I’m still being dense:

> On 13 Sep 2016, at 22:56, Jack Jansen  wrote:
> 
> It’s hardcoded in the Python executable, I’m afraid:-(
> 
> Just tried “python -s -S -v”, and the Extras/lib/python is still in sys.path.
> 
> That wasn’t a very smart move by the Apple engineers, I guess….

But this is the framework (non-apple!) build!…

And, again: why isn’t everyone seeing this all the time? (And why didn’t I see 
it before?)

> What you could do (but this is getting rather hacky) is create a 
> /Library/Python/2.7/site-packages/removeSystemExtras.pth where you import sys 
> and manually remove the Extras entries. Be careful, putting code (as opposed 
> to pathnames) into a .pth file requires the line to start with “import “.
> 
> Jack
> 
>> On  13-Sep-2016, at 23:37 , Andrew Jaffe  wrote:
>> 
>> Hi,
>> 
>> 
>>> On 13 Sep 2016, at 22:26, Jack Jansen  wrote:
>>> 
>>> You’re absolutely right (both on SIP and on 
>>> /Library/Frameworks/Python.framework probably being a python.org install), 
>>> sorry for the confusion.
>>> 
>>> This seems to be due to the way Apple has done the “Extras” directory, and 
>>> adding things there to sys.path.
>>> 
>>> See for example https://github.com/pypa/pip/issues/2468
>>> 
>>> If you can get rid of 
>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python 
>>> in sys.path you should be all set.
>> 
>> Thanks, guys.
>> 
>> Indeed, these /System/Library dirs are in sys.path:
>> 
>>   In [1]: import sys
>>   In [2]: print [p for p in sys.path if 'System' in p]
>>   
>> ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
>>  
>> '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’]
>> 
>> But I’m still confused: why is this problem only showing up now? Is the same 
>> setup that everyone has? Or is it just me for some reason? How and where 
>> would sys.path be set to this, and how and where should I change it? 
>> (Without disabling SIP, please!)
>> 
>> Andrew
>> 
>> 
>> 
>> 
>> 
>> 
>> 
 On  13-Sep-2016, at 22:59 , Glyph Lefkowitz  
 wrote:
 
 
> On Sep 13, 2016, at 12:05 PM, Jack Jansen  wrote:
> 
> I think 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>  is a very old location for storing Python packages. Recently things have 
> been installed in /Library/Python/2.7/site-packages.
> 
> Could it be that you’ve installed pyobjc a couple of OSX releases ago?
 
 This is always worth checking ;).  Particularly if it was a few Setuptools 
 releases ago.  Also worth checking: ~/Library/Python.
 
> And could it be that the OSX upgrade that introduced SIP somehow didn’t 
> clean out user-installed things from /Library/Frameworks before turning 
> off write permission?
 
 SIP locks down /System, not /Library.
 
> A possible workaround is to turn off SIP (or boot from the recovery 
> partition), record what is in 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>  and then clean it out. Then after a reboot re-install the packages 
> you’re still using.
 
 This should be an _absolute_ last resort, though.  You should be able to 
 clean out /Library just fine.  If you have a 
 /Library/Frameworks/Python.framework, that's probably Python.org python, 
 not system python.
 
 -glyph
>>> 
>>> --
>>> Jack Jansen, , http://www.cwi.nl/~jack
>>> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>>> 
>>> 
>>> 
>> 
> 
> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Jack Jansen]

It’s hardcoded in the Python executable, I’m afraid:-(

Just tried “python -s -S -v”, and the Extras/lib/python is still in sys.path.

That wasn’t a very smart move by the Apple engineers, I guess….

What you could do (but this is getting rather hacky) is create a 
/Library/Python/2.7/site-packages/removeSystemExtras.pth where you import sys 
and manually remove the Extras entries. Be careful, putting code (as opposed to 
pathnames) into a .pth file requires the line to start with “import “.

Jack

> On  13-Sep-2016, at 23:37 , Andrew Jaffe  wrote:
> 
> Hi,
> 
> 
>> On 13 Sep 2016, at 22:26, Jack Jansen  wrote:
>> 
>> You’re absolutely right (both on SIP and on 
>> /Library/Frameworks/Python.framework probably being a python.org install), 
>> sorry for the confusion.
>> 
>> This seems to be due to the way Apple has done the “Extras” directory, and 
>> adding things there to sys.path.
>> 
>> See for example https://github.com/pypa/pip/issues/2468
>> 
>> If you can get rid of 
>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python 
>> in sys.path you should be all set.
> 
> Thanks, guys.
> 
> Indeed, these /System/Library dirs are in sys.path:
> 
>In [1]: import sys
>In [2]: print [p for p in sys.path if 'System' in p]
>
> ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
>  
> '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’]
> 
> But I’m still confused: why is this problem only showing up now? Is the same 
> setup that everyone has? Or is it just me for some reason? How and where 
> would sys.path be set to this, and how and where should I change it? (Without 
> disabling SIP, please!)
> 
> Andrew
> 
> 
> 
> 
> 
> 
> 
>>> On  13-Sep-2016, at 22:59 , Glyph Lefkowitz  wrote:
>>> 
>>> 
 On Sep 13, 2016, at 12:05 PM, Jack Jansen  wrote:
 
 I think 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
  is a very old location for storing Python packages. Recently things have 
 been installed in /Library/Python/2.7/site-packages.
 
 Could it be that you’ve installed pyobjc a couple of OSX releases ago?
>>> 
>>> This is always worth checking ;).  Particularly if it was a few Setuptools 
>>> releases ago.  Also worth checking: ~/Library/Python.
>>> 
 And could it be that the OSX upgrade that introduced SIP somehow didn’t 
 clean out user-installed things from /Library/Frameworks before turning 
 off write permission?
>>> 
>>> SIP locks down /System, not /Library.
>>> 
 A possible workaround is to turn off SIP (or boot from the recovery 
 partition), record what is in 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
  and then clean it out. Then after a reboot re-install the packages you’re 
 still using.
>>> 
>>> This should be an _absolute_ last resort, though.  You should be able to 
>>> clean out /Library just fine.  If you have a 
>>> /Library/Frameworks/Python.framework, that's probably Python.org python, 
>>> not system python.
>>> 
>>> -glyph
>> 
>> --
>> Jack Jansen, , http://www.cwi.nl/~jack
>> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>> 
>> 
>> 
> 

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Andrew Jaffe]

Hi,


> On 13 Sep 2016, at 22:26, Jack Jansen  wrote:
> 
> You’re absolutely right (both on SIP and on 
> /Library/Frameworks/Python.framework probably being a python.org install), 
> sorry for the confusion.
> 
> This seems to be due to the way Apple has done the “Extras” directory, and 
> adding things there to sys.path.
> 
> See for example https://github.com/pypa/pip/issues/2468
> 
> If you can get rid of 
> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in 
> sys.path you should be all set.

Thanks, guys.

Indeed, these /System/Library dirs are in sys.path:

In [1]: import sys
In [2]: print [p for p in sys.path if 'System' in p]

['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', 
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’]

But I’m still confused: why is this problem only showing up now? Is the same 
setup that everyone has? Or is it just me for some reason? How and where would 
sys.path be set to this, and how and where should I change it? (Without 
disabling SIP, please!)

Andrew







>> On  13-Sep-2016, at 22:59 , Glyph Lefkowitz  wrote:
>> 
>> 
>>> On Sep 13, 2016, at 12:05 PM, Jack Jansen  wrote:
>>> 
>>> I think 
>>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>>  is a very old location for storing Python packages. Recently things have 
>>> been installed in /Library/Python/2.7/site-packages.
>>> 
>>> Could it be that you’ve installed pyobjc a couple of OSX releases ago?
>> 
>> This is always worth checking ;).  Particularly if it was a few Setuptools 
>> releases ago.  Also worth checking: ~/Library/Python.
>> 
>>> And could it be that the OSX upgrade that introduced SIP somehow didn’t 
>>> clean out user-installed things from /Library/Frameworks before turning off 
>>> write permission?
>> 
>> SIP locks down /System, not /Library.
>> 
>>> A possible workaround is to turn off SIP (or boot from the recovery 
>>> partition), record what is in 
>>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>>  and then clean it out. Then after a reboot re-install the packages you’re 
>>> still using.
>> 
>> This should be an _absolute_ last resort, though.  You should be able to 
>> clean out /Library just fine.  If you have a 
>> /Library/Frameworks/Python.framework, that's probably Python.org python, not 
>> system python.
>> 
>> -glyph
> 
> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Jack Jansen]

You’re absolutely right (both on SIP and on 
/Library/Frameworks/Python.framework probably being a python.org install), 
sorry for the confusion.

This seems to be due to the way Apple has done the “Extras” directory, and 
adding things there to sys.path.

See for example https://github.com/pypa/pip/issues/2468

If you can get rid of 
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in 
sys.path you should be all set.

> On  13-Sep-2016, at 22:59 , Glyph Lefkowitz  wrote:
> 
> 
>> On Sep 13, 2016, at 12:05 PM, Jack Jansen  wrote:
>> 
>> I think 
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>  is a very old location for storing Python packages. Recently things have 
>> been installed in /Library/Python/2.7/site-packages.
>> 
>> Could it be that you’ve installed pyobjc a couple of OSX releases ago?
> 
> This is always worth checking ;).  Particularly if it was a few Setuptools 
> releases ago.  Also worth checking: ~/Library/Python.
> 
>> And could it be that the OSX upgrade that introduced SIP somehow didn’t 
>> clean out user-installed things from /Library/Frameworks before turning off 
>> write permission?
> 
> SIP locks down /System, not /Library.
> 
>> A possible workaround is to turn off SIP (or boot from the recovery 
>> partition), record what is in 
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>  and then clean it out. Then after a reboot re-install the packages you’re 
>> still using.
> 
> This should be an _absolute_ last resort, though.  You should be able to 
> clean out /Library just fine.  If you have a 
> /Library/Frameworks/Python.framework, that's probably Python.org python, not 
> system python.
> 
> -glyph

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Jack Jansen]

I think 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
is a very old location for storing Python packages. Recently things have been 
installed in /Library/Python/2.7/site-packages.

Could it be that you’ve installed pyobjc a couple of OSX releases ago?

And could it be that the OSX upgrade that introduced SIP somehow didn’t clean 
out user-installed things from /Library/Frameworks before turning off write 
permission?

A possible workaround is to turn off SIP (or boot from the recovery partition), 
record what is in 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
and then clean it out. Then after a reboot re-install the packages you’re still 
using.

Jack
> On  13-Sep-2016, at 20:50 , Andrew Jaffe  wrote:
> 
> Dear Chris and Glyph,
>> 
>> On Sunday, September 11, 2016, Andrew Jaffe  wrote:
>> Dear Ronald,
>> 
>> Thanks, as usual, for all this.
>> 
>> I have upgraded to the GM version of 10.12 on the beta track. I use the 
>> python.org framework builds of python.
>> 
>> When I do "pip list --outdated", I get a long list:
> 
> ….
> 
>> If I do the usual "pip --upgrade" for these, it fails, seemingly because of 
>> permissions (Apologies, but I don't have access to the messages anymore): it 
>> is clearly trying to delete these versions which seem to live in 
>> /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, of 
>> course, due to permissions (and system integrity protection).
>> 
>> You can, in fact, do the upgrade with the "--ignore-installed" flag in pip 
>> (although there's still a problem with pyobjc-framework-Message).
>> 
>> So: are these errors expected? Is it something in my particular setup? Or 
>> the beta program? Is "--ignore-installed" the correct solution?
>> 
>> Thanks,
>> 
>> Andrew
>> 
>>> On 13 Sep 2016, at 16:13, Christopher Barker  wrote:
>>> 
>>> If you are dealing with stuff in /System, then you are dealing with the Ape 
>>> installed Python, not the Python.org build.
>>> 
>>> It's easy for "pip" and python to get out of sync. 
>>> 
>>> Try "which pip" to see which pip you are running.
>>> 
>>> This is why I recommend encoding pip via:
>>> 
>>> python -m pip [args]
> 
> [I tried to comment via the gmane newsgroup version of the lists and my 
> messages never appeared so I hope this works…]
> 
> Just to be clear, I am indeed using the framework pip, which is part of why 
> this is so confusing. In the past, as far as I know, it’s never tried to have 
> anything to do with /System. Again, I don’t know if it’s something about 
> macOS 10.12 Sierra, or my particular setup that is the problem. Also, to be 
> clear, there are no PYTHON* or other environment variables that would affect 
> the python path. Here is a failing session…
> 
> (Aside: I understand that "pyobjc-framework-Message” is actually a bad 
> example: it is the only package that even —-ignore-installed actually fails 
> on, because it has the "--single-version-externally-managed” problem which is 
> a different kettle of fish. But I think the above error message is the same 
> as the one that I would get for any of the other packages in question. Note 
> that pip2 install works fine for packages other than those in my original 
> list.)
> 
> $ command which pip2
> /Library/Frameworks/Python.framework/Versions/2.7/bin/pip2
> 
> $ pip2 install --upgrade pyobjc-framework-Message
> Collecting pyobjc-framework-Message
>  Using cached pyobjc-framework-Message-3.1.1.tar.gz
> Requirement already up-to-date: pyobjc-core>=3.1.1 in 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
> (from pyobjc-framework-Message)
> Requirement already up-to-date: pyobjc-framework-Cocoa>=3.1.1 in 
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
> (from pyobjc-framework-Message)
> Installing collected packages: pyobjc-framework-Message
>  Found existing installation: pyobjc-framework-Message 2.5.1
>Uninstalling pyobjc-framework-Message-2.5.1:
> Exception:
> Traceback (most recent call last):
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/basecommand.py",
>  line 215, in main
>status = self.run(options, args)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/commands/install.py",
>  line 317, in run
>prefix=options.prefix_path,
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_set.py",
>  line 736, in install
>requirement.uninstall(auto_confirm=True)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_install.py",
>  line 742, in uninstall
>paths_to_remove.remove(auto_confirm)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_uninstall.py",
>  line 115, in remove
>

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

[Andrew Jaffe]

Dear Chris and Glyph,
> 
> On Sunday, September 11, 2016, Andrew Jaffe  wrote:
> Dear Ronald,
> 
> Thanks, as usual, for all this.
> 
> I have upgraded to the GM version of 10.12 on the beta track. I use the 
> python.org framework builds of python.
> 
> When I do "pip list --outdated", I get a long list:

….

> If I do the usual "pip --upgrade" for these, it fails, seemingly because of 
> permissions (Apologies, but I don't have access to the messages anymore): it 
> is clearly trying to delete these versions which seem to live in 
> /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, of 
> course, due to permissions (and system integrity protection).
> 
> You can, in fact, do the upgrade with the "--ignore-installed" flag in pip 
> (although there's still a problem with pyobjc-framework-Message).
> 
> So: are these errors expected? Is it something in my particular setup? Or the 
> beta program? Is "--ignore-installed" the correct solution?
> 
> Thanks,
> 
> Andrew
> 
>> On 13 Sep 2016, at 16:13, Christopher Barker  wrote:
>> 
>> If you are dealing with stuff in /System, then you are dealing with the Ape 
>> installed Python, not the Python.org build.
>> 
>> It's easy for "pip" and python to get out of sync. 
>> 
>> Try "which pip" to see which pip you are running.
>> 
>> This is why I recommend encoding pip via:
>> 
>> python -m pip [args]

[I tried to comment via the gmane newsgroup version of the lists and my 
messages never appeared so I hope this works…]

Just to be clear, I am indeed using the framework pip, which is part of why 
this is so confusing. In the past, as far as I know, it’s never tried to have 
anything to do with /System. Again, I don’t know if it’s something about macOS 
10.12 Sierra, or my particular setup that is the problem. Also, to be clear, 
there are no PYTHON* or other environment variables that would affect the 
python path. Here is a failing session…

(Aside: I understand that "pyobjc-framework-Message” is actually a bad example: 
it is the only package that even —-ignore-installed actually fails on, because 
it has the "--single-version-externally-managed” problem which is a different 
kettle of fish. But I think the above error message is the same as the one that 
I would get for any of the other packages in question. Note that pip2 install 
works fine for packages other than those in my original list.)

$ command which pip2
/Library/Frameworks/Python.framework/Versions/2.7/bin/pip2

$ pip2 install --upgrade pyobjc-framework-Message
Collecting pyobjc-framework-Message
  Using cached pyobjc-framework-Message-3.1.1.tar.gz
Requirement already up-to-date: pyobjc-core>=3.1.1 in 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
(from pyobjc-framework-Message)
Requirement already up-to-date: pyobjc-framework-Cocoa>=3.1.1 in 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages 
(from pyobjc-framework-Message)
Installing collected packages: pyobjc-framework-Message
  Found existing installation: pyobjc-framework-Message 2.5.1
Uninstalling pyobjc-framework-Message-2.5.1:
Exception:
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/basecommand.py",
 line 215, in main
status = self.run(options, args)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/commands/install.py",
 line 317, in run
prefix=options.prefix_path,
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_set.py",
 line 736, in install
requirement.uninstall(auto_confirm=True)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_install.py",
 line 742, in uninstall
paths_to_remove.remove(auto_confirm)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_uninstall.py",
 line 115, in remove
renames(path, new_path)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/utils/__init__.py",
 line 267, in renames
shutil.move(old, new)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", 
line 299, in move
copytree(src, real_dst, symlinks=True)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", 
line 208, in copytree
raise Error, errors
Error: 
[('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py',
 
'/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py',
 "[Errno 1] Operation not permitted: 

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

[Andrew Jaffe]

Dear Ronald,

Thanks, as usual, for all this.

I have upgraded to the GM version of 10.12 on the beta track. I use the 
python.org framework builds of python.


When I do "pip list --outdated", I get a long list:

 altgraph (0.10.2) - Latest: 0.12 [sdist]
 macholib (1.5.1) - Latest: 1.7 [sdist]
 modulegraph (0.10.4) - Latest: 0.12.1 [sdist]
 py2app (0.7.3) - Latest: 0.10 [sdist]
 pyobjc-core (2.5.1) - Latest: 3.1.1 [sdist]
 pyobjc-framework-Accounts (2.5.1) - Latest: 3.1.1 [sdist]
   
 pyOpenSSL (0.13.1) - Latest: 16.1.0 [wheel]
 xattr (0.6.4) - Latest: 0.8.0 [sdist]

If I do the usual "pip --upgrade" for these, it fails, seemingly because 
of permissions (Apologies, but I don't have access to the messages 
anymore): it is clearly trying to delete these versions which seem to 
live in /System/Library/Frameworks/Python.framework/Versions/2.7/. This 
fails, of course, due to permissions (and system integrity protection).


You can, in fact, do the upgrade with the "--ignore-installed" flag in 
pip (although there's still a problem with pyobjc-framework-Message).


So: are these errors expected? Is it something in my particular setup? 
Or the beta program? Is "--ignore-installed" the correct solution?


Thanks,

Andrew

p.s. none of these issues arise with Python3/pip3, of course.

On 22/07/2016 14:46, Ronald Oussoren wrote:

Hi,

I’m slowly working my way through the SDK headers for macOS 10.12 during idle 
time at EuroPython2016, from the frameworks with small diffs to those with 
larger diffs.

There are at the moment about 26 frameworks I haven’t looked at at all, and 
another 10 where I know I have to do some more work. The rest should have up to 
date metadata on my machine, but haven’t been tested on macOS 10.12 yet (and 
that won’t change until I get around to actually installing a VM running 10.12).

All of this was done using the headers in the Xcode 8 beta 2, I haven’t looked 
at the incremental changes to the SDK in beta 3 yet (and likely won’t until I 
have made a pass through all frameworks).  That said, the diffs from beta 2 to 
later beta’s and the final release should be fairly small (he wrote hopefully).

What needs to be done to get proper support for 10.12:

* Finish updating the metadata.  I suspect that this is a couple of days work, 
I have worked may way through the diffs of a fairly large number of frameworks, 
but haven’t looked at the more complicated ones yet (such as Foundation and 
AppKit). Also, a fairly large subset of the frameworks I have looked at didn’t 
have any significant updates compared to 10.11 (but some of them still had 
large textual diffs due to restructuring of header files).

* Install a 10.12 VM and run tests there. This will likely result in more work, 
there’s already a pull request about NSSecureCoder warnings on 10.12 that needs 
looking into and there’s bound to be more issues.

* Do the build and test dance on older OSX releases.
   The annoying bit for that: there’s a know issue with building on OSX 10.7, 
see issue #100. I haven’t been able to look into that yet
   because I don’t have an VM with 10.7 on my laptop and haven’t been able to 
install 10.7 there yet. I probably have such a VM on
   an external disk somewhere, but I’m not sure about that.

When all that is done I can do a release that includes 10.12 support, with some 
luck around the time of the 10.12 release itself. I’ll definitely push the 
metadata updates to bitbucket once I’ve finished looking through the 10.12 SDK 
diffs.

In the longer run I want to provide wheels for PyObjC, but that requires more 
work. In particular, I only want to do that after automating more of the 
release work because I’ve noticed that I’m already postponing doing new 
releases due to the amount of work and don’t want to make things worse in that 
regard.

BTW. I’ll likely won’t work on metadata updates during the EP2016 sprints, my 
current plan is to keep the tradition of working on PEP 447 alive and try to 
actually get it accepted this year.

Ronald

PS. “A couple of days work” probably means that it will take me several 
calendar weeks to actually finish the work because I have limited time to work 
on this and don’t want to spent all that time on this rather tedious work.

[#100]: 
https://bitbucket.org/ronaldoussoren/pyobjc/issues/100/cannot-find-interface-declaration-for
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Pyobjc-dev mailing list
pyobjc-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev




___