Continuing the discussion in #417
The processing section should ideally be either dynamic since new methods might be added in future. And even if not, putting an /ENTRY[entry] for each of the processing methods seems cumbersome.
I think with a decorator, this could section could perhaps be entirely autogenerated e.g.
has all keys heirarchically arranged, so one just needs to parse them (it should rather be calibration/energy_calibration/.. than energy_calibration/calibration, so that all calibrations can come under that section).
Also, in/after #429 we should definitely add package name/version/etc. to the metadata so the workflow is completely reproducible.
Continuing the discussion in #417 The processing section should ideally be either dynamic since new methods might be added in future. And even if not, putting an /ENTRY[entry] for each of the processing methods seems cumbersome. I think with a decorator, this could section could perhaps be entirely autogenerated e.g.
has all keys heirarchically arranged, so one just needs to parse them (it should rather be calibration/energy_calibration/.. than energy_calibration/calibration, so that all calibrations can come under that section).
Also, in/after #429 we should definitely add package name/version/etc. to the metadata so the workflow is completely reproducible.