Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pylab import fails for non-framework python installs on OS X #2361

Closed
ngoldbaum opened this issue Aug 30, 2013 · 9 comments
Closed

pylab import fails for non-framework python installs on OS X #2361

ngoldbaum opened this issue Aug 30, 2013 · 9 comments

Comments

@ngoldbaum
Copy link
Contributor

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.

The relevant yt issue is here: https://bitbucket.org/yt_analysis/yt/issue/642/cannot-import-pylab-on-os-x-using

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.

@mdboom
Copy link
Member

mdboom commented Aug 30, 2013

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?

@mrterry
Copy link
Contributor

mrterry commented 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
Copy link
Contributor

mrterry commented 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
Copy link
Contributor Author

@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
Copy link
Contributor

mrterry commented 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
Copy link
Contributor Author

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

Hi guys, @ngoldbaum @mdboom,
Thanks your discussion. This problem puzzled me for a long time~~

@WeatherGod
Copy link
Member

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
Copy link
Member

Closing this as (my understanding) is that this is a fundamental issue with OSX.

Also see #3367 and links there in.

@efiring

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants