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

Runtime detection for default backend #3679

Closed
felixonmars opened this issue Oct 20, 2014 · 15 comments
Closed

Runtime detection for default backend #3679

felixonmars opened this issue Oct 20, 2014 · 15 comments

Comments

@felixonmars
Copy link
Contributor

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.

@tacaswell
Copy link
Member

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

@jenshnielsen
Copy link
Member

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

  1. 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.
  2. 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.

@tacaswell tacaswell added this to the v1.5.x milestone Oct 20, 2014
@mdboom
Copy link
Member

mdboom commented Oct 20, 2014

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.

@ruidc
Copy link

ruidc commented Oct 20, 2014

What about just on the first startup?

.

@mdboom
Copy link
Member

mdboom commented Oct 20, 2014

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.

@tacaswell
Copy link
Member

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.

@felixonmars
Copy link
Contributor Author

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)

@mdboom
Copy link
Member

mdboom commented Oct 21, 2014

@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.

@WeatherGod
Copy link
Member

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)
.

@efiring
Copy link
Member

efiring commented Oct 22, 2014

@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?

@felixonmars
Copy link
Contributor Author

@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 😄

@WeatherGod
Copy link
Member

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)
.

@petehuang
Copy link
Contributor

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

@anntzer
Copy link
Contributor

anntzer commented Aug 1, 2017

xref #8613 (comment)

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@anntzer anntzer modified the milestones: needs sorting, v3.0 Sep 19, 2018
@anntzer
Copy link
Contributor

anntzer commented Sep 19, 2018

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

@anntzer anntzer closed this as completed Sep 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants