Re: [Pythonmac-SIG] py2app 0.12 and modulegraph 0.14 released

[Glyph Lefkowitz]

> On Feb 22, 2017, at 2:39 AM, Ronald Oussoren  wrote:
> 
> Hi,
> 
> I’ve just pushed py2app 0.12 and modulegraph 0.14 to PyPI. Both primarily 
> contain bugfixes.
> 
> I had hoped to fix more issues in these releases, but that hasn’t worked out 
> and the fixed bugs are serious enough to not delay the release any more. On 
> to the next release…

Thanks for the release, Ronald!  Looking forward to some of those fixes, and 
good luck on the next batch :-).

-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] apple-Python and TLS 1.0

[Glyph Lefkowitz]

> On Jan 12, 2017, at 6:10 AM, Jack Jansen  wrote:
> 
> Ok, so this is a real problem:-(
> 
> Again, I’m not deep enough into the SSL stuff to really understand this (and 
> specifically whether it needs a new openssl module, a new libssl, both, 
> something else, ….), but I’d like to think of ways to fix this before the 
> shit hits the fan for all poor mac Python users out there, if possible. And 
> that includes people who aren’t even aware they’re macPython users because 
> they use some app that uses Python under the hood…..
> 
> So a couple of questions:
> 
> 1. Is this fixable by Apple, by providing a security update to various OSX 
> versions that would include a newer python/libssl/whatever? 

Yes.  Apple should really be including a private OpenSSL with Python.  But they 
probably won't do that.

> 1a. Would this still fall under Apple’s idea of “security update”?

No, it would probably be a Major-OS sort of thing.

> 1b. Do we have any chance of making Apple interested in fixing this?

It's doubtful that they will update OpenSSL directly.  But they might include a 
new version of Python with a different approach to basic TLS (see the 'tls' 
module in my other response)

> 2. Is this fixable with an installer that would somehow override the openssl 
> module, so that installing this one thing would make the whole Apple-Python 
> installation work again?

Yes and no.  You could fix this by replacing the 'ssl' module with a wrapper 
that replicates it based on 'pyOpenSSL', which is a layer over 'cryptography', 
but this doesn't help users bootstrap via Pip; it would be easier to just tell 
them to get a different Python.
> 
> 3. Failing that, I assume its the end of the line for Apple-Python, and we’ll 
> have to steer end users towards installing a python.org version. Right?

Homebrew is by far my most preferred option (easier to get updates, easier to 
get PyPy, easier to make multiple versions play nicely, more tuned for 
developers, etc etc etc).  But python.org  is a reasonable 
option as well.  And there are lots of other reasons not to tell users to use 
the system-provided Python.

> 3a. If that’s the case, is there something we could ask of the pip 
> developers, the PyPi maintainers, whoever else to help the poor end users? 
> I.e. get them to release a version that would not say “ssl v1 invalid foobar 
> get lost” but in stead “you appear to be using Apple Python which does not 
> support current security measures, please see www.example.com for more 
> information”.

There's no way to do this purely from PyPI's side, but with a little help from 
Apple it's doable.

Another option here is to build the mac Python installers differently so 
they're more user-friendly, and rather than a .pkg make a .app, so that users 
who have sufficiently little command-line expertise to be able to get something 
like Homebrew to behave properly would be able to get on-screen instructions 
and prompts that would help them get set up with a correct command linee.

-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] apple-Python and TLS 1.0

[Glyph Lefkowitz]

> On Jan 10, 2017, at 9:21 AM, Kevin Ollivier  wrote:
> 
> Hi Jack,
> 
> No, I think you're spot on, this is a big problem. Actually, 2.7.9-2.7.12, 
> even the Python.org ones, are already somewhat broken because they use 
> Apple's ancient OpenSSL version. All the ciphers supported by that version of 
> OpenSSL are ones that are regarded as insecure now, so most modern servers, 
> including big ones like AWS, don't allow them anymore. Because of this you 
> can't even download a newer OpenSSL from the OpenSSL web site using Python. 
> :( 

Let's remember that the actual end-of-life here is 18 months out.  It would not 
be desirable to "fix" this problem by clinging to TLS 1.0 even longer; Fastly 
is shutting it off for a lot of very good reasons.

In between here and there are a variety of events, including a new OS release 
from apple.  When it enters beta we can loudly encourage Apple to include new 
and better crypto with Python - that probably does not mean a new 'ssl' module, 
but something more like the new 'tls' module PEP that Cory Benfield has been 
championing (in large part as a response to this).

You can see that discussion here: 
https://mail.python.org/pipermail/security-sig/2017-January/000126.html 
.

Finally, system Python has a lot of issues (unrelated to this, for example, it 
can't be 'dtrace'd, which eliminates a ton of super-useful debugging tools, 
including the OS X equivalent of 'strace'), and I've been gently discouraging 
users from using it for years.  (I say this as an ex- myself.)  Tell users to 
install Python (and PyPy!) from Homebrew, and they will generally have a much 
better time.

If we do nothing, this is going to be a huge disaster.  But the responsible 
people are highly motivated and are quite actively doing things.  If you want 
to make sure users have a good experience, helping them out would definitely be 
advised :).

> It surprised me to find that the Python community wasn't really aware of this 
> problem. For one project I worked on we actually re-coded all our download 
> code to use the Cocoa HTTPS classes via PyObjC, and this was a couple years 
> back. Don't know how many others out there have been fighting with it. 


Cryptography ships with its own OpenSSL, which means you can side-step a lot of 
these issues; install requests[security] and you get better HTTPS.  Or install 
from Homebrew, or python.org , or Anaconda.

-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] py2app release delayed

[Glyph Lefkowitz]

> On Dec 18, 2016, at 12:39 PM, Ronald Oussoren  wrote:
> 
> Hi,
> 
> I had hoped to release a new version of py2app today, but didn’t due to 
> problems with macholib that resulted in broken application bundles. The good 
> news is that I found the cause of that breakage and reverted the patch that 
> caused it.
> 
> I did fix a number of bugs on the tracker last week (the number of open 
> issues decreased from 94 to 72), and implemented a useful new feature: 
> support for “@loader_path” in shared libraries, which is used in wheels 
> processed with delocate 
>  >
>  such as the wheels for Pillow.
> 
> Because this is turning into a fairly large release I’d appreciate if people 
> could test the code in the repository with their applications. To install 
> first install altgraph-0.13, then install modulegraph, macholib and py2app 
> from their bitbucket repositories 
> (https://bitbucket.org/ronaldoussoren/modulegraph 
> , 
> https://bitbucket.org/ronaldoussoren/macholib 
>  and 
> https://bitbucket.org/ronaldoussoren/py2app 
> ).

Can you translate these URLs into (pinned) URLs suitable for a 
requirements.txt?  I'm not used to doing this with hg or bitbucket.  If so I'd 
be happy to test with Mimic.

-g


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

[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 3.2 released

[Glyph Lefkowitz]

> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote:
> 
> 
>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>> 
>> 
>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I’ve pushed PyObjC 3.2 to PyPI (finally…). The major new feature in this 
>>> version is support for OSX 10.12 (Sierra) and the new APIs introduced in 
>>> this version of OSX.
>> 
>> 
>> 
>>> There is also a backward incompatible change: the default method signature 
>>> is calculated differently than before. This will primarily affect code that 
>>> adds python-only method to a class, like so:
>>> 
>>> class MyObject (NSObject):
>>>  def amethod(self, a, b): pass
>> 
>> Huh, I didn't even realize that was possible before.  Hopefully none of my 
>> code will be affected as a result :-).
> 
> It wasn’t really documented, but I wouldn’t be surprised if someone relies on 
> the previous behavior…
> 
>> 
>> Is there any chance that now this release is done, wheel builds might be on 
>> the horizon? :)
> 
> Maybe.  The important bit w.r.t. wheel builds is that they must be automated, 
> otherwise releases take too much time and I end up not doing releases at all. 
>  That said, automating this shouldn’t be too hard and should be able to save 
> me some time in the end (I currently also test manually…)

If manual source releasing is `python setup.py sdist && twine upload dist/*`, 
then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine 
upload dist/*`.  It doesn't seem like that should be a crushing maintenance 
burden :-).

Although perhaps there's something I'm missing?  The subtleties of binary 
compatibility often escape me.

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

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

[Glyph Lefkowitz]

> On Oct 6, 2016, at 2:56 AM, Andrew Jaffe <a.h.ja...@gmail.com> wrote:
> 
> On 17/09/2016 18:59, Glyph Lefkowitz wrote:
>> 
>>> On Sep 17, 2016, at 9:27 AM, Ned Deily <n...@python.org> wrote:
>>> 
>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote:
>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h.ja...@gmail.com
>>>>> <mailto:a.h.ja...@gmail.com>> 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 <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 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-dev] PyObjC and macOS 10.12 (Sierra)

[Glyph Lefkowitz]

> On Oct 11, 2016, at 2:26 PM, Ronald Oussoren  wrote:
> 
> BTW. Has anyone experience with using LLDB on Sierra? I’m currently running 
> Sierra in a VM and for some reason LLDB doesn’t appear to work, in an SSH 
> session I cannot start programs at all and on the console a crashing bug in 
> the interpreter exists the interpreter instead of breaking into the debugger. 
> That’s rather annoying when you’re trying to a debug a crash on 10.12 that 
> doesn’t happen on 10.11.

Ever since the introduction of SIP, system-level debugging tools like LLDB have 
worked very poorly for me, even on self-built executables.  I don't see a 
difference in its behavior on 10.11 vs. 10.12 though.  I can run it on `curl` 
from Homebrew, but not `python`; my guess being that Python is trying to 
dlopen() some SIP-protected thing whereas `curl` is loading only things from 
Homebrew?

If it's a VM, then system integrity is less of a concern; have you tried just 
blanket disabling SIP to see if that improves the situation?  I've had some 
luck with other tools (dtrace, mostly) working in that configuration.  (I had 
to totally disable SIP though, disabling one flag at a time didn't work.)

-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 <n...@python.org> wrote:
> 
> On 2016-09-13 19:33, Glyph Lefkowitz wrote:
>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h.ja...@gmail.com
>>> <mailto:a.h.ja...@gmail.com>> 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 <a.h.ja...@gmail.com> wrote:
> 
> On 17/09/2016 18:59, Glyph Lefkowitz wrote:
>> 
>>> On Sep 17, 2016, at 9:27 AM, Ned Deily <n...@python.org> wrote:
>>> 
>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote:
>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h.ja...@gmail.com
>>>>> <mailto:a.h.ja...@gmail.com>> 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 <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