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
Please describe the use case that requires this feature.
Options in config files change between ctapipe versions, so it would be nice to have a way to do the following
mark a config option as deprecated with a message explaining why or what option to use instead if the parser encounters it
be able to attach some metadata to config files, like the version used to generate them (which is already written in comment form in allow YAML and TOML config files and multiple configs #1856) to also be able to check if the format is compatible.
Everything still works fine without these, as traitlets validates all config options, but with this it makes the user experience a bit better as more useful messages can be generated.
Describe the solution you'd like
Just adding a deprecated field to the trait metadata might work:
Then just need code to look for them and print out warnings.
for the version metadata, we could create a blank Component for that called Metadata (or ctapipe or somthing) , with traits that get read when any Tool is created, e.g.:
Please describe the use case that requires this feature.
Options in config files change between ctapipe versions, so it would be nice to have a way to do the following
Everything still works fine without these, as traitlets validates all config options, but with this it makes the user experience a bit better as more useful messages can be generated.
Describe the solution you'd like
Just adding a
deprecated
field to the trait metadata might work:Then just need code to look for them and print out warnings.
for the version metadata, we could create a blank Component for that called Metadata (or
ctapipe
or somthing) , with traits that get read when any Tool is created, e.g.:The text was updated successfully, but these errors were encountered: