From in-person discussion:

1. I'm in favour of making inline plots the default, see Make matplotlib inline backend the default when loaded in IPython kernel ipython/ipython#6424.
2. The --matplotlib flag will break with IPython 3, and I think config will be needed to do the same thing.
3. Forcing matplotlib to load will slow down kernel start
4. The 'notebook' image probably shouldn't try to load matplotlib, because it may not be installed. Not sure what happens in this case.

Addressed the fourth point just now by only introducing --matplotlib inline on the ipython/scipyserver image.

@takluyver Can you elaborate on point 2? Breaking --matplotlib seems like a bad thing to do...

--matplotlib is a kernel flag, not a frontend flag. it does not make sens with julia kernel, ruby kernel, bash, ocaml, haskel, ...etc. keeping it break all theses kernel, so it is going to be droped.

ah, ok. If I understand the distinctions, it will still be there for the console version of ipython (that is at bash ipython --matplotlib will still work as expected)?

Sorry, I am not as up on all of the terminology/naming conventions as I should be.

Yes, --matplotlib will still exist, just the notebook server will not accept the argument. ie:

$ ipython --matplotlib // ok
$ ipython qtconsole --matplotlib // no, qtconsole can connect to julia
$ ipython notebook --matplotlib // no, notebook can run haskell

setting c.IPKernel.matplotlib will work, as it targets only IPython kernel.
actually you will even be allowd to have notebook with some --matplotlib kernel and soem without --matplotlib if you like.

Sorry, I am not as up on all of the terminology/naming conventions as I should be.

No problem, we can't ask everyone to follow everything.

I think it will actually still work for the qtconsole as well, but I wouldn't rely on that always being the case.

I think it will actually still work for the qtconsole as well, but I wouldn't rely on that always being the case.

Yep it was more a comment on how it should be that how it is :-)

For the sake of the current release of IPython, I'll advocate for this on the scipyserver image.

Since --matplotlib can slow down startup for every kernel, especially on slow-IO VMs, making inline the default matplotlib backend (in matplotlibrc) might be a lighter touch that solves the same problem.

Setting up a non-root user is causing some weird issues. The kernel keeps restarting.

Looks like the kernel restarting is happening because I'm running exec ipython notebook...

With that out of the way, it appears that matplotlib doesn't like the current $DISPLAY variable.

Off to the zoo, I'll touch this up again later.

@rgbkrk do you know why execing the notebook causes the kernels to get restarted forever? I ran into the exact same issue when trying to set a raw ipython notebook command for CMD or ENTRYPOINT (which ultimately translates into those commands being exec'ed I think). I fixed the issue to by restructuring my Dockerfile to call a script as its CMD the same way you do, but I haven't yet figured out why the alternative calling method makes ipython unhappy.

Not sure what is causing that. I ended up having to shelve that earlier to
spend family time.

Without the exec, you can't ctrl-c to kill the running notebook server.

On Wednesday, September 10, 2014, Scott Sanderson [email protected]
wrote:

@rgbkrk https://github.com/rgbkrk do you know why execing the notebook
causes the kernels to get restarted forever? I ran into the exact same
issue when trying to set a raw ipython notebook command for CMD or
ENTRYPOINT (which ultimately translates into those commands being exec'ed
I think). I fixed the issue to by restructuring my Dockerfile to use call a
script as its CMD the same way you do, but I haven't yet figured out why
the alternative calling method makes ipython unhappy.

—
Reply to this email directly or view it on GitHub
#7 (comment).

Kyle Kelley (@rgbkrk https://twitter.com/rgbkrk; http://lambdaops.com)

Forgot to mention, exec as root works just fine. This just affects introducing a default user in the container and running the notebook on top of that.

Trying out nbAgg out for the first time:

What should the default matplotlibrc hold?

As a side note, nbagg is broken in 1.4.0 in py3, there is a PR that fixes it (matplotlib/matplotlib#3464) and we are planning to do 1.4.1 at the end of the month.

@tacaswell That's too bad.

On a side note, I'm noticing that nbAgg takes us back to the whole figure, ..., plot workflow. It's explicit, but then doesn't play well with default pandas workflow, e.g. df.plot().

What backend should I setup? I'm happy to accept a PR for an "opinionated best" matplotlibrc.

%matplotlib inline, pylabtools

I am not sure why nbagg requires an explicit call to show (cc @pelson, @mdboom). I suspect that if you just throw a plt.show() after the pandas calls it will work.

I think activating the inline backend sets up some hooks that run after a cell has executed, to grab the current figure and display it. It's probably possible to do something similar in nbagg, if mpl likes that model.

Do the hooks live in the ipython or mpl source tree?

IPython. See IPython.kernel.zmq.pylab.backend_inline.flush_figures and IPython.core.pylabtools.configure_inline_support.

If those hooks get brought in to matplotlib itself, could this become as simple as setting the matplotlibrc backend to inline?

backend: inline

That would be sweet!
It would mean no more use of %matplotlib inline and just pure python !?

Envoyé de mon iPhone

Le 12 sept. 2014 à 21:07, Kyle Kelley [email protected] a écrit :

If those hooks get brought in to matplotlib itself, could this become as simple as setting the matplotlibrc backend to inline?

backend: inline
—
Reply to this email directly or view it on GitHub.

Looking at this very quickly, I think that flush_figures can be generalized a bit and move over to mpl, but I don't think the hook-registration should.

cc @mdboom This might be folding into the is_interactive work.

Closing until we figure out the right way to do the inlining automagically with matplotlib.