ginga
ginga copied to clipboard
ejeschke
Make loaders discoverable via entry points
This makes loaders for a Ginga viewer discoverable via entry points. This will make it possible to write 3rd-party loaders that are not bundled with Ginga.
Loaders are consolidated in ginga.util.io. Legacy stubs with warning on import are left in ginga.util.io_rgb and ginga.util.io_fits.
I like the concept but +1,557 −1,541 😱
Also, how backward compatible is this?
The large line change is because I left stubs in place for backward compatibility for anyone that might be importing io_fits or io_rgb from the previous location. The actual operation of the opener hasn't really changed as far as API.
Not quite ready for testing or review yet...
@pllim, do you have time to take a look and/or test? This is the last PR to be merged for 4.0, unless we want to try to tackle #1011. I pushed the due date for 4.0 to 2022-12-15.
Don't be daunted by LOC change, almost all is due to moving io_fits.py and io_rgb.py from ginga.util to ginga.util.io, but leaving placeholders in the old location--thus it looks like two new files and big changes to the old two files. There is no significant change to the loaders. I will probably add some documentation still.
do you have time
Not much. Maybe I can look at the documentation when you add them and go from there. It is unlikely that STScI will be adding their own loaders at this point.
@pllim, I updated the documentation in doc/dev_manual/internals.rst. Since I haven't created a "ginga-loader-template" repo, I don't have new instructions on that. For this PR, just updated the code example that loads HDF5 images and a bit of wording. It recommends installing a new loader using the old ginga_config.py technique (which still works).
Have a look if you have time. Would like to put out a release by the 20th.
I don't think I have time to really review this, so if you think it is ready and it is backward compatible, feel free to merge. Thanks!