origins

[thejohnfreeman]

It will be helpful for users if an application can spit out its final configuration annotated with the origins of each value, e.g. source code, configuration file, environment variable, or command line argument. That way they can be sure no unknown overrides are sneaking into the configuration. Configurations would need to carry with them not just the values of variables but their origins, so that they survive compositions.

[sampsyo]

That sounds useful too.

This appears currently in Confit in the ConfigSource class, which is a dict subclass. This currently keeps track of two pieces of data: filename and default (which means this came from the app's defaults). This is useful for many reasons, including the kind of diagnosis that you mention. One other way we use it in beets is to let filenames that occur in the configuration be relative to the configuration file they appear in.

[thejohnfreeman]

The relative filename feature is very attractive, I have to say. I have two requests though:

1. For each variable, the origin should generalize to an opaque string filled in by the function that creates the configuration. For example, in my libray, from_file would use 'file.yaml:123', from_env would use 'env:VAR_NAME', and from_argv would use 'argv:--var-name'.
2. Deserializers like the one that converts a relative filename to an absolute one should be functions separate from the configuration interface. That way clients do not need to poke in the existing configuration classes to implement new, cool features like that.

[sampsyo]

Deserializers like the one that converts a relative filename to an absolute one should be functions separate from the configuration interface.

I couldn't agree more. In the current Confit, for example, this is (hopefully, if memory serves) contained in the Filename template.