Details
-
Type:
Bug
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Labels:
-
Story Points:4
-
Urgent?:No
Description
The lsst.pipe.base.ConfigOverrides class provides a centralized location for config-handling functionality that was previously integrated into the Gen 2 CmdLineTask. However, it provides much poorer diagnostics than the code it replaces. In particular:
- errors in config files are propagated upward as the original error from executing the config code; information about which file is the problem is lost.
- errors in field-value pairs give different messages depending on whether the field name has a ".". These messages are not equally informative:
$ --config bar=foo
error: cannot apply config: 'bar'
$ --config bar.baz=foo
error: cannot apply config: 'ApdbConfig' object has no attribute 'bar'
- errors in field-value pairs report the config field under most circumstances, but not on the branch that uses literal_eval
- I can't test the Python override, but like the config file, it seems to only report the exception and not the code that triggered it.
- errors in instrument config files, like those in user-specified config files, do not report which file contained the error.
Add exception handling to lsst.pipe.base.ConfigOverrides and lsst.obs.base.Instrument that gives the user enough information to figure out what is causing config problems.
Attachments
Issue Links
Activity
Description |
The {{lsst.pipe.base.ConfigOverrides}} class provides a centralized location for config-handling functionality that was previously integrated into the Gen 2 {{CmdLineTask}}. However, it provides much poorer diagnostics than the code it replaces. In particular:
* errors in config files are propagated upward as the original error from executing the config code; information about *which* file is the problem is lost. * errors in field-value pairs give different messages depending on whether the field name has a ".". These messages are not equally informative: {noformat} $ --config bar=foo error: cannot apply config: 'bar' {noformat} {noformat} $ --config bar.baz=foo error: cannot apply config: 'ApdbConfig' object has no attribute 'bar' {noformat} * errors in field-value pairs report the config field under most circumstances, but not on the branch that uses {{literal_eval}} * I can't test the Python override, but like the config file, it seems to only report the exception and not the code that triggered it. * errors in instrument config files, like those in user-specified config files, do not report which file contained the error. Add exception handling to {{lsst.pipe.base.ConfigOverrides}} and {{lsst.obs.base.Instrument}} that gives the user enough information to figure out what is causing config problems. |
The {{lsst.pipe.base.ConfigOverrides}} class provides a centralized location for config-handling functionality that was previously integrated into the Gen 2 {{CmdLineTask}}. However, it provides much poorer diagnostics than the code it replaces. In particular:
* errors in config files are propagated upward as the original error from executing the config code; information about _which_ file is the problem is lost. * errors in field-value pairs give different messages depending on whether the field name has a ".". These messages are not equally informative: {noformat} $ --config bar=foo error: cannot apply config: 'bar' {noformat} {noformat} $ --config bar.baz=foo error: cannot apply config: 'ApdbConfig' object has no attribute 'bar' {noformat} * errors in field-value pairs report the config field under most circumstances, but not on the branch that uses {{literal_eval}} * I can't test the Python override, but like the config file, it seems to only report the exception and not the code that triggered it. * errors in instrument config files, like those in user-specified config files, do not report which file contained the error. Add exception handling to {{lsst.pipe.base.ConfigOverrides}} and {{lsst.obs.base.Instrument}} that gives the user enough information to figure out what is causing config problems. |
Component/s | obs_base [ 10719 ] |