Plots are not displayed in the observation planning example on RTD

[mwcraig]

The documentation of the observation planning example in coordinates used to include the plots (see the 1.0 version of the docs) but no longer does (see the 1.0.1 version or the latest version)

[astrofrog]

Actually all the plots are missing... (in modeling too)

[astrofrog]

The error is:

/home/docs/checkouts/readthedocs.org/user_builds/astropy/envs/latest/local/lib/python2.7/site-packages/astropy-1.1.dev12121-py2.7-linux-x86_64.egg/astropy/convolution/kernels.py:docstring of astropy.convolution.MexicanHat2DKernel:59: WARNING: Exception occurred in plotting astropy-convolution-MexicanHat2DKernel-1
 from /var/build/user_builds/astropy/checkouts/latest/docs/api/astropy.convolution.MexicanHat2DKernel.rst:
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py", line 515, in run_code
    exec code in ns
  File "<string>", line 4, in <module>
  File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 2881, in imshow
    ax = gca()
  File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 803, in gca
    ax =  gcf().gca(**kwargs)
  File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 450, in gcf
    return figure()
  File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 423, in figure
    **kwargs)
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_tkagg.py", line 79, in new_figure_manager
    return new_figure_manager_given_figure(num, figure)
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_tkagg.py", line 87, in new_figure_manager_given_figure
    window = Tk.Tk()
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1767, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
TclError: no display name and no $DISPLAY environment variable

[astrofrog]

We should maybe try and set the backend in conf.py. Any better ideas? (cc @mdboom)

[mdboom]

This is on readthedocs? Seems like a readthedocs bug, as their matplotlib should never be set to a GUI backend.

(The conf.py solution is probably fine, though it would override anything a user may have set, such as preferring Mac OSX rendering to Agg rendering)...

[astrofrog]

By the way the first warning in the docs build is:

/usr/lib/pymodules/python2.7/matplotlib/__init__.py:1173: UserWarning:  This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

I'll ask on #readthedocs (or whatever their IRC channel is)

[astrofrog]

Issue opened: readthedocs/readthedocs.org#1195

[embray]

Before you open an issue on RTD (too late already, I know) that might have something to do with this: astropy/astropy-helpers@8e17135

In that case it is setting the correct backend. But it might be doing things out of order.

[embray]

(And FWIW that change was tested against the docs build on Travis and didn't have any warnings. It might have something to do with the matplotlib version being used in the doc build.)

[embray]

Although, in my change it is calling matplotlib.use() before importing pyplot, so, not sure what that's about...

[astrofrog]

[re-wrote this comment since it was confused before]

@embray - there are several points here:

• I think it still makes sense to have the RTD issue open - the backend is getting set to interactive before anything to do with our code, and that shouldn't happen.
• I can see why you set the backend in ah_bootstrap.py but I really don't think we should set it in astropy_helpers/__init__.py - the reason why is that for example for glue, I use astropy_helpers only for the sphinx extensions, so it gets imported for that with import astropy_helpers. However, by then matplotlib has also been imported for other reasons, and I think that having import astropy_helpers try and set the backend is an undesirable side-effect. If we absolutely must keep it, then we should at least filter the warning out.
• This made me realized that Astropy master is using astropy-helpers 1.0.0, not 1.0.1, so maybe we should update that

ccing @mdboom since he may have thoughts on this too.

[embray]

I don't know what other solution there is than what's there, since without it some package installs literally CANNOT proceed because of the matplotlib issue.

I think it could be taken out of astropy_helpers/__init__.py sooner or later--that was only necessary because ah_bootstrap.py can't upgrade itself, so the fix has to go somewhere else that can get upgraded. So eventually it can be removed from there. I'm not really sure what you're talking about with glue though. Why would matplotlib be imported during setup in such a way that the backend would matter? I'd rather see an actual problem than a vague hypothetical one.

[astrofrog]

@embray - the actual problem in glue is this failure:

https://travis-ci.org/glue-viz/glue/jobs/54781259

Which is that there is a warning emitted during the sphinx build (the matplotlib backend issue). This in turn is due to the fact that we list astropy_helpers's extensions in the following file:

https://github.com/glue-viz/glue/blob/master/doc/conf.py

then at the end of the file, we import something from glue, which in turn imports matplotlib.pyplot, setting the backend automatically (just because importing matplotlib.pyplot does, there is no use() call in glue. Then, sphinx imports astropy_helpers which causes the warning to be emitted and the sphinx build to therefore fail. Of course, one solution is to import astropy_helpers in conf.py before glue is imported, but to me that sounds like a hack/workaround, not a proper solution. Do you see what I mean?

[embray]

I think the workaround is fine for now. After all, the thing in astropy_helpers itself is a workaround that is only needed until
a) All packages have upgraded their copy of ah_bootstrap.py to the latest one and,
b) Matplotlib is released with a fix to its issue

[astrofrog]

Plots in docs fixed :) RTD was setting the backend to TkAgg. And it sounds like the thing in astropy_helpers is temporary anyway, so closing this.