Add support for passing charmcraft.yaml as metadata

[gruyaume]

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.

METADATA = yaml.safe_load(Path("tests/unit/charms/tls_certificates_interface/v4/dummy_requirer_charm/charmcraft.yaml").read_text())
state_in = scenario.State(
    config={"common_name": "example.com"},
)
ctx = scenario.Context(
    charm_type=DummyTLSCertificatesRequirerCharm,
    meta=METADATA,
)

Logs

scenario.runtime.InconsistentScenarioError: Inconsistent scenario. The following errors were found: config option 'common_name' in state.config but not specified in config.yaml.

Desired state

self.ctx = scenario.Context(
    charm_type=DummyTLSCertificatesRequirerCharm,
    meta=METADATA,
)

Workaround

self.ctx = scenario.Context(
    charm_type=DummyTLSCertificatesRequirerCharm,
    meta=METADATA,
    config=METADATA["config"],
    actions=METADATA["actions"],
)

[tonyandrewmeyer]

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.

[PietroPasotti]

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.

[tonyandrewmeyer]

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.