Programmatically detect whether the inline backend is available

[lukelbd]

I want to programatically detect whether the %matplotlib inline backend is available, because I am writing a package that tries to automatically activate either the qt or inline backends. Unfortunately I cannot just try to run %matplotlib inline and catch any errors, because it fails silently. Try the following test code:

%matplotlib inline
import matplotlib.pyplot as plt
f, ax = plt.subplots()

• In ipython, <Figure size 432x288 with 1 Axes> is displayed in the terminal (so the display hook defaults to showing the repr of the Figure instance).
• In jupyter console, my OS opens up a window containing a temporary PNG file with a name like tmp2qea4370.PNG.... which is really weird.

This thread helped -- I can differentiate terminal ipython from any jupyter session. However I cannot differentiate jupyter console from jupyter qtconsole and jupyter notebook. This prevents my users from using jupyter console with my package.

Running on macOS 10.15.2, and jupyter version info is below:

$ jupyter --version
jupyter core     : 4.6.1
jupyter-notebook : 6.0.2
qtconsole        : 4.6.0
ipython          : 7.11.1
ipykernel        : 5.1.3
jupyter client   : 5.3.4
jupyter lab      : not installed
nbconvert        : 5.6.1
ipywidgets       : 7.5.1
nbformat         : 5.0.3
traitlets        : 4.3.3

[ivanov]

@lukelbd sorry it took so long for anyone to get back to you.

However I cannot differentiate jupyter console from jupyter qtconsole and jupyter notebook.

I'm not sure what behavior you'd want, given that you can connect to a kernel started in a notebook using either console or qtconsole (via --exisiting flag). What %matplotlib inline does, roughly, is make matplotlib figures send along their rendered contents in a image/png key of the output mime bundle. Then it's up to the client to display those, which notebook and qtconsole know how to do, but console does not, so it falls back on the plain text repr version.

This prevents my users from using jupyter console with my package.

You've probably figured out a path forward here, but it may be unavoidable to expose some ability to your end-users to specify which sort of behavior they need.