You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we we have string literals scattered throughout code that are supposed to "track" the config defaults then this is code duplication and could be solved by adding a config property to ops.CharmMeta. This currently supports most of the top-level keys of a charmcraft.yaml file and Scenario already effectively has this, so it's quite viable.
Currently this is achievable with loading the charmcraft.yaml yourself. Another way is to use stored state but both options enable varying coding styles across charms which could be solved with the self.meta.
The text was updated successfully, but these errors were encountered:
There are situations where we want to compare against or set the default config values of a charm config option.
E.g. A user sets an invalid log level and so the charm sets the default value.
If we we have string literals scattered throughout code that are supposed to "track" the config defaults then this is code duplication and could be solved by adding a config property to ops.CharmMeta. This currently supports most of the top-level keys of a charmcraft.yaml file and Scenario already effectively has this, so it's quite viable.
Currently this is achievable with loading the charmcraft.yaml yourself. Another way is to use stored state but both options enable varying coding styles across charms which could be solved with the
self.meta
.The text was updated successfully, but these errors were encountered: