You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: