Matplotlib dependency not listed in setup.py

[rmjarvis]

When setting up Travis CI for GalSim, I discovered that starlink-pyast has a hidden dependency of matplotlib at the top of Grf.py. Since none of the other packages we use in GalSim require matplotlib, it didn't get installed on the Travis sandbox, and import starlink.Atl led to an ImportError from the matplotlib dependency.

Even with matplotlib installed, it's still an annoying import, since it has to set up the font cache the first time it is imported. This takes time and adds noise to the output:

/home/travis/virtualenv/python2.7.12/lib/python2.7/site-packages/matplotlib/font_manager.py:273:
UserWarning: Matplotlib is building the font cache using fc-list. This may take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This may take a moment.')

Possible solutions in order of (my) preference:

1. Make matplotlib an optional dependency and only import Grf (and thus matplotlib) if the user calls Atl.plotframeset. i.e. Move the line import starlink.Grf as Grf into this function.
2. Make matplotlib an optional dependency and only import matplotlib in the Grf functions that use it. Then import starlink.Grf as Grf is quick, and matplotlib would only have to be imported if the user calls the functions in Grf that need it.
3. Make matplotlib an official dependency by adding it to setup.py, but also do (1) or (2) to avoid the above warning.
4. Make matplotlib an official dependency, and continue to needlessly import matplotlib whenever Atl is imported.

Thanks for your consideration. :)

[timj]

Sorry about that. I'll take a look.

[timj]

I've had a quick look and I think I would be inclined to fix the Atl interface so that it does something like:

try:
    import starlink.Grf as Grf
except ImportError:
    Grf = None

and then raise an exception in the plotframeset routine if Grf is None. Ideally we would have put the ATL plot routines in a different support package but it's a bit late to do that now.

[rmjarvis]

I suppose that would solve the problem, but it seems less than ideal from an end user's perspective, since it swallows the traceback for the ImportError. If the user thought they had matplotlib installed, this wouldn't give them any feedback as to why import starlink.Grf is failing.

Why not just put import starlink.Grf in the plotframeset function itself? Is this just to conform to PEP8, or is there a more concrete reason to prefer putting this at the top?

Remember, "A foolish consistency is..." not always the best choice. :)

[timj]

Hmmm. Yes, I tend to prefer imports at the top of code files rather than buried in the middle, but in this case, given that the failure mode is identical (you get an unexpected error some time after your program starts rather than at import time), I guess having the real error trigger inside plotframeset is better than an error we make up ourselves when plotframeset is called.

[timj]

Ok, I'm sleep-addled but I've put in an attempted fix in #15.