Do desimodel scripts require fitsio for performance? about desimodel

[sbailey]

All of these could use astropy.io.fits instead, but that seems low priority. In the context of the python3 conversion, I'm supportive of changes that make the conversion easier (e.g. adding unit tests), but I caution against making otherwise unnecessary cleanup changes while we are simultaneously trying to do before/after comparisons for python 2.7 vs. 3.5.

[weaverba137]

Since we are not certain of fitsio's Python 3 readiness, I would argue that converting to astropy.io.fits would make the conversion easier.

[sbailey]

Late breaking news:

• fitsio v0.9.10 was tagged today including the latest py3.5 fixes
• Erin Sheldon confirmed by email that earlier tags also worked for py3.5 and this fix was a corner case involving variable length strings (which admittedly might impact us in the current-but-to-be-deprecated FILTER column of the fibermap table; I haven't checked)

[dkirkby]

The last time I checked, fitsio did not support any windows platforms. Do we make any claims about supported platforms for the desihub stack?

[sbailey]

Answering @dkirkby's question from a few months ago:
We support Linux and Mac and do not support Windows (though I don't know if we've written that down anywhere).

For the record: We still have some historical fitsio code in some DocDB -> data reformatting scripts, but let's not change that unless it actually is a problem (if it is, open a new issue with the details). It's not needed for performance, but we shouldn't spend our time replacing one working library with an different working library.