modularity / fedmod

#8 Reconsider approach to generated file formatting
Closed Opened by ncoghlan.

Closed
Reopen Issue

Currently, fedmod just uses modulemd.ModuleMetadata.dump() to write out the files.

However, as noted in https://pagure.io/modularity/modularity-tools/issue/44 & https://pagure.io/modulemd/issue/53, dump() doesn't yet work as we might hope.

I'm thinking that it may make sense to define fedmod's own internal file writing routine for now, and then look to get that merged back in to modulemd upstream later, rather than having to depend on the latest & greatest (potentially unreleased) version of modulemd.

Thoughts @ignatenkobrain, @dhodovsk, @ttomecek?

@ncoghlan it is DUPLICATE/NOTABUG in modulemd =) see https://pagure.io/modulemd/issue/40

Although I'm not opposed to generate modulemd on your own.

OK, given that, I think it will definitely make sense to introduce our own formatter that emphasises human readability of the result.

That way we can also incorporate @ttomecek's requests from https://pagure.io/modularity/modularity-tools/issue/44:

  • integrate the explanatory comments from https://pagure.io/modulemd/blob/master/f/spec.yaml
  • avoid any use of YAML's inline formats

Given that, it would probably make sense to follow Ansible's lead and use Jinja2 for the template generation, rather than trying to define it all as pure Python code.

This will go into libmodulemd so that all module tools can benefit from it.

Metadata Update from @karsten:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.