MNT: Deprecate and eventually remove TEAL?

[pllim]

It has no maintainer and not enough users to warrant maintenance overhead. Currently it still works, but for how long? Should we start a deprecation period and eventually remove its usage? Do we really need to cling onto the IRAF era epar interface?

Our packages that are affected from a quick GitHub search on spacetelescope org on 2020-02-05:

• This package (stsci.tools)
• acstools
• calcos
• costools
• drizzlepac
• fitsblender
• reftools
• skypac
• stistools
• stwcs
• subpixal
• wfc3tools
• INS stuff (scripts, packages, training, docs) -- We need to communicate to them so they do the work

[cdsontag]

[sniff sniff]

[stsci-hack]

One suggestion from Tyler (INS/ACS) would be to replace the Tk backend for TEAL with a web-interface instead. If practical, this would retain the current functionality users rely on to run complex tasks like astrodrizzle while potentially being easier to maintain and perhaps merge into or use with Jupyter notebooks. This would not be too much of a stretch for TEAL in one (minor?) aspect: TEAL already brings up the task's help documentation in a web browser if a browser can be opened.

It would also be less of a shock to users who are already relying on TEAL to run 'astrodrizzle', which has a lot of visibility with the mission. As a reminder, the HST mission office remains concerned about maintaining the community's trust in our code and wants to insure that our code (astrodrizzle included) remains as easy to use as possible so that the community will use it as much as possible to process HST data.

Retire TEAL? OK, but only when a replacement is available for those already relying on TEAL.

[pllim]

cc @tddesjardins

[hcferguson]

I think that GUI input of configuration is important for our user community. Not just for astrodrizzle. And I agree with @stsci-hack that using a web-browser form is the modern way to go. It would be nice if we could just use an existing one rather than build from scratch.

I think there are practical advantages of the GUI interface that aren't replicated in text-based config files (or the python-script approach, which I'm not a fan of for a variety of reasons).

• built in help on each parameter
• ability to have dropdowns
• real-time validation

The best of both worlds is a GUI that writes a nice well-documented human-readable config file that includes the descriptions of the parameters clearly delineated from the parameters themselves. Then you can use the GUI and the config file interchangeably.

It would be best if we can just use a library package rather than write one ourselves.

[pllim]

What do you all think about a replacement like https://flexx.readthedocs.io/en/stable/guide/index.html ? I think electron might be too heavy handed. Other ideas welcome.

UPDATE: flexx does not seem to work well from within an installed package. Its beta stage of development might mean it is too early for us to use in production.

[pllim]

As for parameter verification, perhaps astropy.config can do the job for us, especially since we already have astropy dependency for FITS I/O (if nothing else). (Or maybe not if whatever package we choose for new GUI also has validation.)