This was an intentional choice from PR 1613. Unfortunately this has caused some downstream headaches for us (speaking on behalf of the yt project).
The issue is that we distribute yt using a bash installer script that builds all of yt's dependencies from source. Now that we've updated to use matplotlib 1.3.0, all pylab imports fail on OS X with a RuntimeError.
Wouldn't it be possible to fallback to another frontend rather than outright failing? Our suggested workaround is to use tkagg instead of macosx but that's a bit nasty since it doesn't fix the fact that pylab is broken out of the box for our OS X users.
For what it's worth, we've never heard of issues with the macosx backend. I guess it wasn't fully working on our non-framework install of python, but the failures were so subtle that no one ever noticed.
You can disable the osx backend in setup.cfg by adding:
[gui_support]
macosx = False
it will then fall back to the next available backend.
My understanding is that the macosx backend has never worked on a non-framework Python, so perhaps in the past a different backend was being selected by default?
Events are broken on non-framework builds, but standard plotting works. For instance, anaconda ships with a non-framework build and mpl 1.2.1. Basic plotting works, but don't try to connect to a key_press_event.
I guess this leads to a reasonable question, should we allow mostly-functional installs of matplotlib? There is the real possibility of getting blamed for events not working, even when warn the user that running non-framework python builds will void the warranty. However, some folks (yt for example) may not use those corners of mpl and may be quite happy otherwise.
@mdboom just tried building matplotlib using your suggested modifications to setup.cfg and pylab still fails to import with the same error in the macosx backend. I can't find the place in the matplotlib codebase where the macosx config option is parsed so I'm not sure if this is a bug of if I should be doing something slightly different.
In setupext.py, BackendMacOSX inherits from OptionalBackendPackage. OptionalBackendPackage.get_config() reads the gui_support section from setup.cfg. get_config() ought to return the value in setup.cfg
Given that there are some deep-level event handling done within mpl, I
would argue that if non-framework build pythons can't process events
correctly, then we are just asking for trouble if we allow non-framework
builds. Furthermore, it is entirely possible that in the future, mpl will
be going with a more event-driven architecture (see the direction of
WebAgg). Therefore, getting users off of non-framework builds will be
important.
Activity
mdboom commented on Aug 30, 2013
You can disable the osx backend in setup.cfg by adding:
it will then fall back to the next available backend.
My understanding is that the macosx backend has never worked on a non-framework Python, so perhaps in the past a different backend was being selected by default?
mrterry commented on Aug 30, 2013
Events are broken on non-framework builds, but standard plotting works. For instance, anaconda ships with a non-framework build and mpl 1.2.1. Basic plotting works, but don't try to connect to a key_press_event.
mrterry commented on Aug 30, 2013
I guess this leads to a reasonable question, should we allow mostly-functional installs of matplotlib? There is the real possibility of getting blamed for events not working, even when warn the user that running non-framework python builds will void the warranty. However, some folks (yt for example) may not use those corners of mpl and may be quite happy otherwise.
ngoldbaum commented on Aug 30, 2013
@mdboom just tried building matplotlib using your suggested modifications to setup.cfg and pylab still fails to import with the same error in the macosx backend. I can't find the place in the matplotlib codebase where the macosx config option is parsed so I'm not sure if this is a bug of if I should be doing something slightly different.
mrterry commented on Aug 31, 2013
In setupext.py, BackendMacOSX inherits from OptionalBackendPackage. OptionalBackendPackage.get_config() reads the gui_support section from setup.cfg. get_config() ought to return the value in setup.cfg
ngoldbaum commented on Aug 31, 2013
ah, it was because I had a typo! Thanks for the guidance @mrterry.
@mdboom's workaround seems sufficient for our purposes. I'm going to leave this open so a matplotlib dev can close it if they agree.
lucktroy commented on Sep 23, 2013
Hi guys, @ngoldbaum @mdboom,
Thanks your discussion. This problem puzzled me for a long time~~
WeatherGod commented on Sep 23, 2013
Given that there are some deep-level event handling done within mpl, I
would argue that if non-framework build pythons can't process events
correctly, then we are just asking for trouble if we allow non-framework
builds. Furthermore, it is entirely possible that in the future, mpl will
be going with a more event-driven architecture (see the direction of
WebAgg). Therefore, getting users off of non-framework builds will be
important.
tacaswell commented on Aug 17, 2014
Closing this as (my understanding) is that this is a fundamental issue with OSX.
Also see #3367 and links there in.
@efiring