Modulo fixing the mac tests...

@anntzer Thank you for considering my comments. It's good not to overload the semantics ofrcParams['backend'].

However, I'm afraid I haven't made myself clear there:

• I'm not in favor of adding any active functionality to rcParams (i.e. changing the current backend by setting the rcParam).
• A list of possible backends as rcParam is basically ok.

Please see my comment#11581 (comment) (which was probably created in parallel to this PR.)

Re: mac failures:
Ithink they are due to the fact that (unlike all other backends, and following@tacaswell's fears), the OSX backend initializes the NSApp during backend import, rather than totally lazily; then, because we always try to import it first, when we later switch to tkagg, things may go awry. Fixing this shouldn't be too hard, just a matter of moving the initialization to a private function and call it in FigureCanvas_init;@tacaswell do you have time to give it a shot?

@timhoffm I agree that the backend doesn't logically belong in the rcParams, but until python-syntax matplotlibrcs happen (if ever, yada yada), the only thing we can set from matplotlibrc is entries in rcParams, and we definitely want a way to set the backend from matplotlibrc. Once python-syntax matplotlibrc happen, we can always move it out and ask people to useuse() (orset_backend, etc.) in their matplotlibrc.py.

Having the entry in the rcParams and the actual backend go out of sync is exactly what I don't want to happen.

I agree, that we want to set thedefault backend from matplotlibrc. Thecurrent backend should not be part of the rcParams. There's no syncing involved if we make that distinction.

@tacaswell do you have time to give it a shot?

I don't have a mac to test on....

I agree, that we want to set the default backend from matplotlibrc. The current backend should not be part of the rcParams. There's no syncing involved if we make that distinction.

for better or worse, the current backend being stashed in rcParams in the existing behavior. I think the weird side effects of setting one rcparam (at risk of setting a very poor precedent) is better than breaking that bit of existing behavior.

I am aware that the current backend being stashed in rcParams is the existing behavior. So far, this is read-only (setting the rcParam when a current backend exists has no effect). This is not great, but both easy to cope with if we want to evolve the API, and likely not used very often.

This PR adds setting-capability through rcParams. IMO it's a movement in the wrong direction. We make more users aware of this poor API. And the added functionality will make it harded to smoothly migrate to a better API later.I strongly suggest not to go down this road.

There are better ways to bring in the backend-switching functionality. Unfortunately, I don't have the time to write the design out now, but I will do so tonight. Please wait with further decisions until then, if at all possible.

@tacaswell You realize that Travis is my main OSX machine? :) Tried to push something, let's see whether it works.
@timhoffm Sure, I'll wait for your design.

Cherry-picked#9993 into this PR as well because the current version of qt_compat fails with NameError (instead of ImportError) when qt bindings are not installed.

#11612 lays out an alternative API design.

Appveyor is of course failing for some reason....

The cherry-pick is due to#11629 (and the fact that this PR explicitly relies on unimportable backends to raise ImportError -- I believe that generically catching any exception is too wide and too likely to hide real bugs). Would be happy for#9993 to be merged in first, or otherwise for#11629 to be fixed separately.

I'm fine with moving the switching logic touse for now. This means that rcParams["backend"] may end up being different from the actual backend in use (if one assigns to it -- note that callinguse will still update the entry in the rcParams), which I don't like, but that would still be an improvement wrt. the current situation. Sounds like a reasonable compromise?

@timhoffm Do you want to give a try at implementing this? The pieces are basically all there, just a matter of moving things around.

As noted on gitter, I can't really follow what this is doing, and it seems to need documentation. I won't block if core folks like@tacaswell,@dopplershift and@anntzer are happy with it, and are willing to maintain it.

Basically, when I originally wrote the PR, there were two goals:

• don't set the default backend in the build, which causes all sorts of problems to packagers and is usually worked around by the redistributors by hard-wiring some value anyways,
• makempl.use() actually switch backend when it can (i.e. staying within the same GUI toolkit, or to a noninteractive toolkit, or as long as no GUI interactive event loop has started), and throw an exception when it cannot, getting rid of the somewhat nonsensicalforce andwarn kwargs touse.

The second part has been removed after the additional PRs by@tacaswell due to disagreements about the API, which I can't say I'mthat happy with (but still thanks for putting together that implementation to move things forward); on the other hand even just having the first part is clearly already an improvement (and not having the second part means that there is less API changes). Moreover, implementing something else in the spirit of the second part remains relatively easy to do now (again, it's mostly a discussion about the API that's needed).

I added a whats new for the backend selection logic. Did not add one for the backend switching (despite that being the name of this branch!) because as@anntzer points out there is still disagreement of what that API should look like (and where it should live) so lets not advertise it widely (yet).

OK, well, four of the most senior devs approved or authored it, and I can't see anything bad in it, so I'm merging. Thanks for the "Whats New" that definitely helped. The documentation issue noted above can be handled post merge if a follow-up PR if deemed necessary before 3.0 is fully released.

Thanks for taking this step by step and deferring the API discussion to 3.1. I've been on holidays and couldn't take part in the final discussion. However, I fully agree with the approach taken so far. 😄