Provide App.describe for use in databases and cli

I’ve been thinking about the idea of App.describe and I think it could be a useful feature. Bringing this out from #191 for a focused discussion while #191 may include much more than this. The motivation is much like that of #191: reproducing analysis and bugs if you’re given just the HDF file.

From the wayback machine,

Yeah, the more I’m thinking about this, the more I seems that a lot of the implementation details about things like plugin versions is really the prerogative of the specific App. For one, there isn’t a guaranteed 1:1 mapping from a python package/version to a given plugin, so enumerating the plugins to get their “versions” gets a bit fraught.

Having an App.describe()->str: function seems like kind of the way to go. ARMI can call it and stuff whatever it gets from the App instance into the db attrs. Seem reasonable?

_Originally posted by @youngmit in https://github.com/terrapower/armi/issues/191#issuecomment-820607055_

My thinking is this:

Expose App.describe() as a command line entry point, like a very verbose version. Could be called either as armi --version -v or armi describe. This could be very useful for reproducing bugs.

Return a dictionary rather than string from App.describe. I think a dictionary would be better as it would allow keys to represent plugin-specific data. The most minimal structure would map a plugin to a version {p: v}. Or, if more diagnostic data could be added in the future, something like {p: {"version": v}}. This could allow plugins that are installed as sub-modules to report not just their “as released” version, but also the commit id as {p: {"version": v, "revision": g}}.

This namespace-like approach could also be used to store absolute paths for executables, data libraries, etc. Things could get a bit messy trying to dump a nested dictionary to HDF, but a JSON-ified string might work.

[youngmit]

Oh yeah, and whatever ends up in that dict would probably be the basis for that forensic db data mentioned in #191. Figure since YAML is a big part of the ARMI ecosystem anyways, we just pump the dict into a YAML string and store that

[youngmit]

We’ve been discussing this some internally, and landed on something pretty close to what you describe. App and Plugin classes will have .describe() method, which just returns dict. Default impl might try to come up with something useful on its own, but mostly expected that the App/Plugin developer implements whatever they think is useful. App.describe() would produce a dict with whatever the App developer wants, and base impl will iterate plugins, calling their describe()s, collecting them into ["plugins"][plugin.name] = plugin.describe().

What specific contents go into the description should I think be left pretty unspecified, and the overall usefulness of the description will be a function of the quality of the .describe() implementations for the various plugins. ARMI can provide some utility things to, say, try to get Git commit SHAs from plugins if they appear to be under source control, and even try to use that as part of the base plugin/app implementations, but other than that leave it up to the developer.

Seem good?