Error when using astropy in lieu of pyfits

[rmjarvis]

The latest version of starlink has a bug in the FitsChan implementation when used in conjunction with astropy.io.fits (imported as pyfits):

$ pip show starlink-pyast

---
Name: starlink-pyast
Version: 3.3
Location: /Library/Python/2.7/site-packages
Requires: 
$ python
Python 2.7.5 (default, Mar  9 2014, 22:15:05) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyfits
>>> pyfits.__version__
'3.0.13'
>>> hdu = pyfits.open('1904-66_TAN.fits')[0]
>>> import starlink.Ast as Ast
>>> import starlink.Atl as Atl
>>> fc = Ast.FitsChan(Atl.PyFITSAdapter(hdu))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.7/site-packages/starlink/Atl.py", line 106, in __init__
    self.pyfits_3_1_0 = ( LooseVersion(pyfits.__version__) >=
AttributeError: 'module' object has no attribute '__version__'
>>> import astropy
>>> astropy.__version__
u'1.0.1'
>>> 

So, since I have astropy as well as pyfits, starlink does import astropy.io.fits as pyfits (which is fine with me -- it's what we do in GalSim too). But astropy.io.fits doesn't have a __version__ attribute. In GalSim, we get around this problem with the following code:

try:
    import astropy.io.fits as pyfits
    # astropy started their versioning over at 0.  (Understandably.)
    # To make this seamless with pyfits versions, we add 4 to the astropy version.
    from astropy import version as astropy_version
    pyfits_version = str( (4 + astropy_version.major) + astropy_version.minor/10.)
    pyfits_str = 'astropy.io.fits'
except:
    import pyfits
    pyfits_version = pyfits.__version__
    pyfits_str = 'pyfits'

Then we just use pyfits_version whenever we want to conditionally do different actions depending on the "pyfits" version. You might want to do something similar here.

For cross-reference, this issue was originally posted by a GalSim user @beckermr here.

[timj]

I think pull #6 must have broken it. We'll look into it.

[rmjarvis]

Actually, looking at PR #6, I think it was intended to fix this exact bug. So once that makes it into a release that gets into pip, I think this will be resolved.

[dsberry]

I have pushed version 3.8.0, which includes PR #6, to pypi.

[rmjarvis]

Thanks. The original issue we were having is fixed with this update. Thanks very much for the quick response. I'm having a separate issue with SIP files, but I'll open a new issue for that one. Closing this now.