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] Phantom Dock menu entries for tkinter dialogs on Mac

[Mark Lutz]

Ah; thanks for checking.  I should have tested under Tk 8.6, but was 
following the stock recommendation at python.org to use ActiveState's
8.5 (as most of the target audience will), and python.org's installers
(which don't support Tk 8.6, but may soon?).

Will upgrade and have a look.  Hopefully, 8.6 will clear up a few other
AS 8.5 oddities too - weirdly slow Text scrolls, windows losing focus 
on popups, and the like - though it largely works well enough to qualify
as compelling, and better than the version shipped with the box.  

Cheers,
--Mark Lutz, http://learning-python.com


> -Original Message-
> From: Kevin Walzer 
> To: pythonmac-sig@python.org
> Subject: Re: [Pythonmac-SIG] Phantom Dock menu entries for tkinter dialogs
>  on Mac
> Date: Tue, 13 Dec 2016 06:50:53 -0500
> 
> On 12/6/16 9:43 PM, Mark Lutz wrote:
> > A simple demo of the problem is attached below: every "destroy" popup
> > lingers on in the launcher's Dock menu after it's closed (whether by
> > the red "X" or the widget.destroy() callback), and remains in the Dock
> > menu until the main window is closed (by widget.quit() or otherwise).
> > This happens whether the script is run by click or command line.
>
> I can't reproduce this using Tkinter built against Tk 8.6.6. There were 
> a lot of issues with menus, the event loop, and so on that have been 
> fixed--I don't recall seeing this exact issue but I did see similar 
> things with "ghost windows" hanging around in a system menu after being 
> destroyed. You may want to update your installation of Tk.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ___
> 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] Need help with Python Library link error in OS X 10.11.6

[Chris Barker]

> brew install --HEAD libimobiledevice
>

odd -- this:

http://brewformulas.org/Libimobiledevice

doesn't make it look like it needs Python.

I think this is a question for the brew folks.

-CHB




> and following error message was displayed at the end of this command run
>
> **
>
> checking consistency of all components of python development
> environment... no
> configure: error:
>  Could not link test program to Python. Maybe the main Python library has
> been
>  installed in some non-standard library path. If so, pass it to configure,
>  via the LDFLAGS environment variable.
>  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
>  ===
> =
>   ERROR!
>   You probably have to install the development version of the Python
> package
>   for your distribution.  The exact name of this package varies among them.
>  ===
> =
>
> ***
>
> I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m"
> as suggested however it failed as it couldn't find "configure" in current
> user's folder. I also searched in other file system to locate "configure"
> but couldn't find it. I need to revolve this Python lib link issue and need
> suggestions on how to do it. Things I need help  on:
> 1. Where can I find "configure" to run the suggested LDFLAGS command. If
> it is not available in my Mac, what is the next step for me.
> 2. Do I need to install any Python builds to get rid of this error and be
> able to run brew install --HEAD libimobiledevice  command successfully.
>
> Thank you
>
> Regards
> Manohar
>
>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>


-- 

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)

[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] Need help with Python Library link error in OS X 10.11.6

[Christopher Barker]

The configure script should come with the source. It is specific to that
particular package, not a system script.

But brew should do that for you anyway.

I have no idea what Appium is, but it looks like it depends on Python --
you probably neeed to install the brew version of Python first.

I would have thought that brew's dependency management would handle that,
but it's worth a try to do it by hand.

-CHB

On Tue, Dec 13, 2016 at 2:28 AM Manohar K Chintala 
wrote:

> Hello Team,
>
> I am setting up Appium for mobile test automation on new Mac with OS X
> 10.11.6 and as part of that I had to run following command.
>
> brew install --HEAD libimobiledevice
>
> and following error message was displayed at the end of this command run
>
> **
>
> checking consistency of all components of python development
> environment... no
> configure: error:
>  Could not link test program to Python. Maybe the main Python library has
> been
>  installed in some non-standard library path. If so, pass it to configure,
>  via the LDFLAGS environment variable.
>  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
>
>  
>   ERROR!
>   You probably have to install the development version of the Python
> package
>   for your distribution.  The exact name of this package varies among them.
>
>  
>
> ***
>
> I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m"
> as suggested however it failed as it couldn't find "configure" in current
> user's folder. I also searched in other file system to locate "configure"
> but couldn't find it. I need to revolve this Python lib link issue and need
> suggestions on how to do it. Things I need help  on:
> 1. Where can I find "configure" to run the suggested LDFLAGS command. If
> it is not available in my Mac, what is the next step for me.
> 2. Do I need to install any Python builds to get rid of this error and be
> able to run brew install --HEAD libimobiledevice  command successfully.
>
> Thank you
>
> Regards
> Manohar
>
>
>
> ___
>
> 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] Examples of vendoring python 3 with py2app

[Cosimo Lupo]

Thank you all for the replies.
I've tried using py2app with a framework python 3.5.2 from Python.org and
can confirm it correctly bundles everything up in the generated app.
I somehow was under the impression that I had to do something special about
it, but it turns out it is much easier than I thought!
Thanks again :)

Cosimo

On 13 December 2016 at 16:21, Christopher Barker 
wrote:

> Have tried it? Back in the day, py2app would embed the entire python
> runtime if you ran it with a non-Apple python.
>
> I haven't tried it with py3, but it may "just work"
>
> You'll know, 'cause you will get a big bundle :-). And you can, of course
> look inside and see what's there.
>
> -CHB
>
>
> On Tue, Dec 13, 2016 at 2:28 AM Cosimo Lupo 
> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hello list,
>>
>>
>>
>>
>>
>> Apologies if this is not the right place to ask about this.
>>
>>
>>
>>
>>
>> I would like to distribute a self-contained OSX app of an application of
>> mine written in Python 3. I've used py2app in the past to ship apps written
>> in Python 2.7, that linked to the system Python framework.
>>
>>
>> Now I'm wondering if I could if and how I could "vendor" Python 3.5
>> inside my py2app-generated app.
>>
>>
>>
>>
>>
>> In the py2app docs I could not find information as to how to embed the
>> python 3.5 interpreter and stdlib alongside the generated .app bundle.
>>
>>
>>
>>
>>
>> Could anyone point me in the right direction, and/or link to existing
>> open source apps that do this?
>>
>>
>>
>>
>>
>> Thank you for your help.
>>
>>
>>
>>
>>
>> --
>>
>>
>> Cosimo Lupo
>>
>>
>>
>>
>>
>>
>> ___
>>
>> 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)

[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] Examples of vendoring python 3 with py2app

[Ronald Oussoren]

> On 11 Dec 2016, at 16:22, Cosimo Lupo  wrote:
> 
> Hello list,
> 
> Apologies if this is not the right place to ask about this.
> 
> I would like to distribute a self-contained OSX app of an application of mine 
> written in Python 3. I've used py2app in the past to ship apps written in 
> Python 2.7, that linked to the system Python framework.
> Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my 
> py2app-generated app.
> 
> In the py2app docs I could not find information as to how to embed the python 
> 3.5 interpreter and stdlib alongside the generated .app bundle.
> 
> Could anyone point me in the right direction, and/or link to existing open 
> source apps that do this?
> 
> Thank you for your help.

py2app will do that automatically unless you either explicitly tell it not to, 
or you use /usr/bin/python (the Apple provided installation of Python).

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

[Pythonmac-SIG] Examples of vendoring python 3 with py2app

[Cosimo Lupo]

Hello list,

Apologies if this is not the right place to ask about this.

I would like to distribute a self-contained OSX app of an application of mine 
written in Python 3. I've used py2app in the past to ship apps written in 
Python 2.7, that linked to the system Python framework.
Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my 
py2app-generated app.

In the py2app docs I could not find information as to how to embed the python 
3.5 interpreter and stdlib alongside the generated .app bundle.

Could anyone point me in the right direction, and/or link to existing open 
source apps that do this?

Thank you for your help.

--
Cosimo Lupo___
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  wrote:
> 
> 
>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz  wrote:
>> 
>> 
>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren  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

[Pythonmac-SIG] Need help with Python Library link error in OS X 10.11.6

[Manohar K Chintala]

Hello Team,

I am setting up Appium for mobile test automation on new Mac with OS X
10.11.6 and as part of that I had to run following command.

brew install --HEAD libimobiledevice

and following error message was displayed at the end of this command run

**

checking consistency of all components of python development environment...
no
configure: error:
 Could not link test program to Python. Maybe the main Python library has
been
 installed in some non-standard library path. If so, pass it to configure,
 via the LDFLAGS environment variable.
 Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
 
  ERROR!
  You probably have to install the development version of the Python package
  for your distribution.  The exact name of this package varies among them.
 

***

I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m"
as suggested however it failed as it couldn't find "configure" in current
user's folder. I also searched in other file system to locate "configure"
but couldn't find it. I need to revolve this Python lib link issue and need
suggestions on how to do it. Things I need help  on:
1. Where can I find "configure" to run the suggested LDFLAGS command. If it
is not available in my Mac, what is the next step for me.
2. Do I need to install any Python builds to get rid of this error and be
able to run brew install --HEAD libimobiledevice  command successfully.

Thank you

Regards
Manohar
___
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-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  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-dev] PyObjC 3.2.1 released

[Ronald Oussoren]

> On 13 Dec 2016, at 04:02, Glyph Lefkowitz  wrote:
> 
> 
>> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren > > wrote:
>> 
>> Hi,
>> 
>> I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues 
>> in PyObjC 3.2, but the primary new feature is that there are now wheels on 
>> PyPI. 
>> 
>> I’ve tested the wheels on OSX 10.12 with the Python.org  
>> “intel” installers (the default download option for the OSX installers) and 
>> Homebrew. The wheels should also work fine with older OSX releases. 
> 
> Thank you *so* much, Ronald :D.  I installed pyobjc onto my laptop just now 
> and didn't even have to go get an icepack out of the freezer first :-).  In 
> under ten seconds, no less, for both python 3.5 and python 2.7.  A glorious 
> day, to be sure.
Great to hear that.

> 
> One minor note - I do notice that the 'pyobjc' package itself has no wheel, 
> even though all its dependents do.  Any chance you could upload 2.7/3.5 
> wheels for that as well?  It would just complete the set :-).

That is intentional. The setup.py for the package pyobjc calculates the 
“install_requires” list at runtime to ensure it will only install framework 
wrappers for frameworks that are actually present.  It might be possible to use 
conditional dependencies for that (see [1]), but I haven’t checked yet if those 
compare version numbers as structured data or strings.  PEP 426 seems to 
indicate they are just strings, and that would be less useful.   

I guess a wheel for the “pyobjc” package could just depend on all framework 
wrappers, that would install some code that isn’t relevant for the current 
machine but wouldn’t result in install failures (which could happen when 
installing all framework wrappers from source).  

Ronald

[1]: http://wheel.readthedocs.io/en/latest/#defining-conditional-dependencies
> 
> Thanks again; this is fabulous,
> 
> -glyph
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! 
> http://sdm.link/slashdot___
> Pyobjc-dev mailing list
> pyobjc-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

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