Make inline the default matplotlib backend

[minrk]

uses recently discovered (c/o @WeatherGod) MPLBACKEND env (matplotlib > 1.5) to make inline the 'default' backend, for users who don't call matplotlib.use() or %matplotlib prior to plotting.

Trigger extra IPython inline setup when inline backend is loaded. We can't call the simpler ip.enable_matplotlib() here because this will be triggered during pyplot import, and enable_matplotlib() imports pyplot which isn't ready yet.

This PR is a sibling of matplotlib/matplotlib#6734

With both PRs, users importing matplotlib and using it without calling %matplotlib <anything> should get reasonable behavior in all of:

• terminal IPython (including 5, where GUI eventloops won't hang anymore)
• qtconsole (inline backend default, gui backends won't hang)
• notebook (same)

Either PR independently solves the hang in notebooks, but together they should do what we have been wanting for a long time.
This should remove the need for us to do anything with an import hook (#82).

SciPy hallway discussions FTW!

cc @tacaswell @mdboom @takluyver @fperez

[WeatherGod]

This gets a +1 from me, at least.

[fperez]

Looks good, but before merging, there should be a quick note in the docs about $MPLBACKEND and our suggested best practice with this. It should clarify:

• what the values should look like: is it just 'inline' or does it have to be a fully qualified name like module://ipykernel.pylab.backend_inline?
• that an explicit %matplotlib foo call still overrides $MPLBACKEND for users who want to change (e.g. having an inline default but opening the GUI one at the terminal).
• how we suggest folks author notebooks: I still think it's best to be explicit in notebooks meant to be shared, so they run equally in all environments irrespective of each user's choice of $MPLBACKEND value.

But I love the improvement!

[WeatherGod]

The MPLBACKEND isn't being created for ipython. It already existed and is
documented in matplotlib. The idea is that ipython is hooking into it for
this single purpose of activating its inline backend if no other backend is
explicitly stated. There is no change to users, as far as I can see.

On Wed, Jul 13, 2016 at 11:41 PM, Fernando Perez [email protected]
wrote:

Looks good, but before merging, there should be a quick note in the docs
about $MPLBACKEND and our suggested best practice with this. It should
clarify:

what the values should look like: is it just 'inline' or does it have
to be a fully qualified name like
module://ipykernel.pylab.backend_inline?

that an explicit %matplotlib foo call still overrides $MPLBACKEND for
users who want to change (e.g. having an inline default but opening the GUI
one at the terminal).

how we suggest folks author notebooks: I still think it's best to be
explicit in notebooks meant to be shared, so they run equally in all
environments irrespective of each user's choice of $MPLBACKEND value.

But I love the improvement!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-G6nGHt6TvVLMe-DCUjMFsjvl45fks5qVa_kgaJpZM4JL_gB
.

[fperez]

Got it. At the very least our docs should mention that with a link to the relevant MPL docs... Users may enter only via our docs, so we want to let them know how we honor this, even if the full details are elsewhere. It's also so it goes into our release notes next time...

[WeatherGod]

True... there is
http://matplotlib.org/faq/environment_variables_faq.html?highlight=mplbackend#envvar-MPLBACKEND
or possibly better:
http://matplotlib.org/devel/coding_guide.html?highlight=mplbackend#developing-a-new-backend

On Wed, Jul 13, 2016 at 11:56 PM, Fernando Perez [email protected]
wrote:

Got it. At the very least our docs should mention that with a link to the
relevant MPL docs... Users may enter only via our docs, so we want to let
them know how we honor this, even if the full details are elsewhere. It's
also so it goes into our release notes next time...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-IqwguPAbtqzRU2KEoUN_OJ8UYGCks5qVbNVgaJpZM4JL_gB
.

[takluyver]

Awesome, nice find!

[takluyver]

@minrk Do you want to add a whatsnew entry, then I think we can merge this.

[tacaswell]

This should probably be configurable so ipympl can over ride this?

[minrk]

@tacaswell it is configurable, via the MPLBACKEND environment variable. This only sets that if it's not already set. Do you think there should be another setting somewhere?

[minrk]

Sorry for the delay, I'm still catching up on email backlog from SciPy. Added note to changelog about it, linking to MPLBACKEND docs.

@fperez I don't think our recommendations should change. %matplotlib inline is explicit and preferable, and still required on matplotlib < 1.5. The MPLBACKEND environment variable sits at a very low priority, so any mechanism by which the user might specify their preference will have higher priority:

• explicitly set MPLBACKEND environment variable
• any call to matplotlib.use('backend')
• any call to %matplotlib [whatever]

The only thing this has higher priority than is .matplotlibrc.

[tacaswell]

Sorry, I was a bit confused.

The ENV only has an effect if it is set before matplotlib is imported for the first time. I am not super familiar with the kernel codebase, but it looks like is always true here.

What ipympl is doing is using mpl.use (https://github.com/matplotlib/jupyter-matplotlib/blob/master/ipympl/__init__.py). I think this is the right thing to avoid subtle import order issues and the semantics of 'you have imported ipympl, you probably want to use ipympl' seems reasonable mpl.use can be used as many times as you want before matplotlib.backends is imported (as that is what we check in use to see if it safe). This works well if there is only one extension, but I can imagine there being multiple packages that are doing the same thing.

As a side note, we are very slowly starting push the pyplot related state all the way into pyplot (but that is only on the master branch at the moment).

[minrk]

I think this is ready to go, and then we can release 4.4. Anything else to do/discuss here?

[takluyver]

Looks good to me