MNT: Deprecate and eventually remove TEAL?

spacetelescope / stsci.tools

STScI utility functions.

https://stscitools.readthedocs.io/en/latest/

BSD 3-Clause "New" or "Revised" License

7 stars 21 forks source link

MNT: Deprecate and eventually remove TEAL? #94

Open pllim opened 5 years ago

pllim commented 5 years ago

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 commented 5 years ago

[sniff sniff]

stsci-hack commented 4 years ago

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 commented 4 years ago

cc @tddesjardins

hcferguson commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.)