Status: To Do
Fix Version/s: None
This is a description of some of the interactions I've had with lsst.verify over the last few weeks. I'm trying to capture the relevant experience so we can triage and determine what we want to do going forward. Note that these mostly have to do with specs, at the moment.
- When dealing with a few levels of inheritance, it's very easy to get confused. It would be nice to be able to introspect what partials went into a particular spec definitions.
- We have been considering the YAML descriptions to be the primary implementation mechanism for defining specifications. With multiple levels of hierarchy, it's easy to make mistakes, via simple typos. We should think about whether we want to continue with YAML as the source of primacy (as opposed to code for example).
- We need some tooling for linting. A good start on this is in DM-18900. Essentially all of my problems that weren't simple typos were due to either redefinitions of specs, or ids of partials shadowing each other.
- Currently, there are a few different styles for spec definitions. I think it would be good to provide advice on best practices as well as to homogenize the definitions we have now.
- The validate_drp specs are very complicated because of so called "compound" specs. These are specs that depend both on the release level, e.g. FY19, and the SRD level, e.g. design. I think we should examine whether these kinds of compound specs should even be defined the way we are currently doing it.
Further stories may appear in the comments.