Runtime detection for default backend · Issue #3679 · matplotlib/matplotlib · GitHub

While I'd like to make every backend available for a distribution package, the Qt5Agg backend will be set as default by matplotlib's installation script, and when a user doesn't have qt5 installed, matplotlib will throw an error if the client application didn't specify a backend.

It would be nice if there could be a fallback logic on runtime so the best-available GUI backend will be chosen as the default backend.

This ties in with a request from the Ipython people to auto detect if you are in a note book and launch nbagg/inline.

I think this is relevant request. It is complicated by two issues as far as I can see.

We usually detect backends by trying to import modules. Usually these are somewhat mutually exclusive and this is done in a subprocess to avoid conflicts between gui frameworks. If doing this at runtime I suspect we need a better way.
Some of the backends contain compiled code (gtk, tk and OSX I think) The dependencies need to be installed at compile time. Other backends (like the Qt ones) don't actually need the backend at compile time but will work if gui library is is installed afterwards. For these backends the only check at compile time only serves to mark them as available.

Yeah -- I think historically the main driver against doing this was the performance/clumsiness of trying to import a bunch of different guis at start up. At the very best, you have the overhead of importing the first gui to try in a separate process, because if that fails, you can't then load another gui in the same process later and expect it to work. And that turns out to be a lot of overhead.

So, unless we can find a way around that -- i.e. a "cheaper" way to detect the installation of GUI frameworks that works across all of our platforms (i.e. there's distro-specific tricks that could be used, but that's going to be a lot of work to maintain all of the combinations), I'm not sure this is doable.

What about just on the first startup?

.

First startup is an interesting idea. We could move the logic we already have during compilation to something that runs, in a child process, on first startup and then saves the result in a config file. Lots of tricky details there, but it might help this use case.

Down side of first start up is that it can mess with people who bounce between backends ex going from running ipython in the terminal to running a notebook. I don't think we can assume that user is always going to want to use mpl the same way as the first time they import pyplot.

For detecting if a GUI library is installed, how about just assuming the toolkit is installed correctly if the module is present? We can detect if a module is present by using the "imp" module without actually import the module, this way we should have a much less overhead for big players like Qt and GTK.

Just an example:

import imp

available_backends = (
    ("qt5agg", "PyQt5"),
    ("qt4agg", "PyQt4"),
    ("gtk3agg", "gi"),
    ("wxagg", "wx"),
)

for backend, module in available_backends:
    try:
        imp.find_module(module)
        break
    except ImportError:
        pass

else:
    # Implement other logic to detect tk?
    pass

print("Best available GUI backend:", backend)

@felixonmars: That last idea could work -- and we could easily detect the IPython notebook in there, too. Are you interested in working that into a pull request? This is the kind of thing that will require a lot of hammering on in various environments and configurations to get all the details right -- having a PR will give us a chance to try it out many places.

Possibly related... I think it might be useful to emit some kind of warning
if plt.show() is called and there are no interactive backends available.
This might cut down on reports of people saying that their scripts exits
immediately with no display.

On Tue, Oct 21, 2014 at 7:59 AM, Michael Droettboom <
notifications@github.com> wrote:

@felixonmars https://github.com/felixonmars: That last idea could work
-- and we could easily detect the IPython notebook in there, too. Are you
interested in working that into a pull request? This is the kind of thing
that will require a lot of hammering on in various environments and
configurations to get all the details right -- having a PR will give us a
chance to try it out many places.

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

@WeatherGod, then if someone develops a script that saves a figure and uses show() for testing and local use, and wants to use the same script on a cloud server, it would generate a warning. Is this a good tradeoff?

@mdboom I'd like to, but I may have to take a look into the current code first as I'm not familiar with it yet 😄

fantastic question. I usually protect my plt.show() with an if-statement
indicating whether or not I want to do a show, and control that through a
command-line option. But it is perfectly valid right now not to do that.
This is probably why I haven't submitted a PR about this yet.

On Wed, Oct 22, 2014 at 3:25 AM, Eric Firing notifications@github.com
wrote:

@WeatherGod https://github.com/weathergod, then if someone develops a
script that saves a figure and uses show() for testing and local use, and
wants to use the same script on a cloud server, it would generate a
warning. Is this a good tradeoff?

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

I believe this continues to stand as a valid request - please read the thread for some useful discussion

xref #8613 (comment)

This is implemented as of 3.0 (#9795 and following PRs).

Runtime detection for default backend · Issue #3679 · matplotlib/matplotlib · GitHub

Repository navigation

Runtime detection for default backend #3679

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Runtime detection for default backend · Issue #3679 · matplotlib/matplotlib · GitHub

Repository navigation

Runtime detection for default backend #3679

Description

Activity

tacaswell commented on Oct 20, 2014

jenshnielsen commented on Oct 20, 2014

mdboom commented on Oct 20, 2014

ruidc commented on Oct 20, 2014

mdboom commented on Oct 20, 2014

tacaswell commented on Oct 20, 2014

felixonmars commented on Oct 21, 2014

mdboom commented on Oct 21, 2014

WeatherGod commented on Oct 21, 2014

efiring commented on Oct 22, 2014

felixonmars commented on Oct 22, 2014

WeatherGod commented on Oct 22, 2014

petehuang commented on Jan 7, 2017

anntzer commented on Aug 1, 2017

anntzer commented on Sep 19, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions