I was writing some config file code for freezerbox, and as part of making a good error message, I needed to know which file each config option was loaded from. AppCLI could provide this information, but currently doesn't. I can think of a few ways to do this:
Add a meta: bool argument to appcli.param(). If True, the resulting attribute would be a Meta instance containing the value of interest and any metadata I can think of, instead of just the raw value. This does require API users to know that the metadata is there, though.
Always store metadata at the instance level, and make it available to classes that define meta = appcli.meta(). This is in line with how appcli.config_attr() works, and won't affect how values are accessed. It would make it more difficult to manually override metadata values, but I can't really think of a valid reason to do that.
Another aspect of the freezerbox application is that I have nested dicts/lists that I would like to update (instead of replace). The metadata should reflect which keys/items came from which sources. This would have to be handled by the merge function, which would then have to take a metadata argument. (I looked for libraries that can optionally pass arguments to callbacks, and found just one: backcall. It's from the author of flit, but it doesn't support required arguments. If I go this route, I'll probably roll my own.) I'd have to provide some metadata aware functions for merging dicts/lists.
I was writing some config file code for freezerbox, and as part of making a good error message, I needed to know which file each config option was loaded from. AppCLI could provide this information, but currently doesn't. I can think of a few ways to do this:
meta: boolargument toappcli.param(). If True, the resulting attribute would be aMetainstance containing the value of interest and any metadata I can think of, instead of just the raw value. This does require API users to know that the metadata is there, though.meta = appcli.meta(). This is in line with howappcli.config_attr()works, and won't affect how values are accessed. It would make it more difficult to manually override metadata values, but I can't really think of a valid reason to do that.Another aspect of the freezerbox application is that I have nested dicts/lists that I would like to update (instead of replace). The metadata should reflect which keys/items came from which sources. This would have to be handled by the merge function, which would then have to take a metadata argument. (I looked for libraries that can optionally pass arguments to callbacks, and found just one:
backcall. It's from the author of flit, but it doesn't support required arguments. If I go this route, I'll probably roll my own.) I'd have to provide some metadata aware functions for merging dicts/lists.