Open gruyaume opened 1 month ago
Support for the unified charmcraft.yaml was added in #91, but only for the autoloading where it finds the file (and under the hood it's basically doing what you describe in the workaround section).
I can see that it would be convenient to just throw an entire YAML file to the metadata argument and have Scenario figure it out.
should we consider in 7.0 to have the unified charmcraft as default?
Context(charm:CharmType, meta:CharmcraftYaml = None)
and offer a helper to_charmcraft_yaml(meta, config, actions)
function?
A less hardline approach would be to keep the Context signature as is, but change the semantics of the 'meta' argument to also accept 'unified charmcraft yaml'. Downside is that with this we'd have to guard against passing a combination of 'charmcraft yaml' + actions and/or config.
should we consider in 7.0 to have the unified charmcraft as default?
Context(charm:CharmType, meta:CharmcraftYaml = None)
and offer a helper
to_charmcraft_yaml(meta, config, actions)
function?
+1
A less hardline approach would be to keep the Context signature as is, but change the semantics of the 'meta' argument to also accept 'unified charmcraft yaml'. Downside is that with this we'd have to guard against passing a combination of 'charmcraft yaml' + actions and/or config.
Yeah, and the names are then confusing I think: even though it's "meta" and not "metadata", having a set of (meta, config, actions) feels very much like you are expected to not have the config/actions in the first arg.
Description
Charmcraft.yaml (replacing metadata.yaml) now removes the need to have different files for metadata, config, and actions. When providing metadata in the charmcraft.yaml format, we get a
InconsistentScenarioError
error because the config option is not recognized.Logs
Desired state
Workaround