fm-orchestrator

#658 Using same type of yaml format
Closed: Invalid Opened by jaruga.

Closed: Invalid
Reopen Issue

I got modules.yaml after $ mbs-build local.

~/modulebuild/builds/module-ruby-master-20170830111056/results/modules.yaml

---
data:
  api:
    rpms: [rubygem-io-console, rubygem-psych, rubygem-minitest, rubygems, ruby-devel,
      ruby-libs, ruby-irb, rubygem-bundler, rubygem-json, rubygem-rake, rubygem-net-telnet,
      rubygem-did_you_mean, rubygem-test-unit, rubygem-xmlrpc, rubygem-bigdecimal,
      rubygem-openssl, ruby, rubygem-rdoc, rubygem-power_assert, rubygems-devel]
...
  components:
    rpms:
      ruby: {buildorder: 101, cache: 'http://pkgs.fedoraproject.org/repo/pkgs/ruby',
        rationale: An interpreter of object-oriented scripting language, ref: master,
        repository: 'git://pkgs.fedoraproject.org/rpms/ruby'}

In modules.yaml, 2 spaces indent, "[]" for sequencing element, "{}" for mapping element.
However below sample, and

But below specification.
https://pagure.io/modulemd/blob/master/f/spec.yaml
And initial file.
https://github.com/fedora-modularity/dependency-report/blob/master/modules/ruby/ruby.yaml

4 spaces indent, "- " for sequencing element, "name: value" for mapping element.
(partly "[]" is used.)

I guess using same format is good.

Maybe we should not use ""[]" for sequencing element, "{}" for mapping element" as much as possible.

why does it matter? also, more compact output file is -- better.

If modules.yaml is one of the files that user checks the result of the mbs-build local,

Matter 1:
My recognition is modularity team is recommending 4 spaces as a indent.
Though personally 2 spaces indent is more popular and my favorite.

But the file is 2 spaces indent. I am confused which is recommended format by modularity team.
Unified format is better than different format, isn't it?

Matter 2:
"[]", "{}" is not easy for human to check the values in the yaml file than "-" and "name: value".

more compact output file is -- better.

I do not understand what you said. What you mean?

User is not supposed to check output modules.yaml.

Okay.
Thanks for the answer.
Feel free to close this ticket.

why does it matter? also, more compact output file is -- better.

You can do diff between the modulemd file in dist-git and what was then the result of the build, to see what was added / used by the build system. If the format and indentation differs, you basically get 2 different files.

@thozza the thing is that composed version contains much more things inside..

If you want to diff, you can reformat yaml in format you used from the beginning..

@thozza the thing is that composed version contains much more things inside..
If you want to diff, you can reformat yaml in format you used from the beginning..

The point is that the tooling should use the same formatting. It is not like people like some way of writing YAML files and they want to force MBS to use it. The documentation and tooling provided by the modularity team is not using consistent formatting. Example can be https://github.com/fedora-modularity/dependency-report/blob/master/modules/ruby/ruby.yaml, which is different from what is produced after the build. Most people will just take this generated modulemd as a base for creating Fedora module, not writing it from scratch.

Yes, I could reformat it, but why should I have to do it by myself? Especially when the tooling could be consistent to be user-friendly and make it easy for people to work with modules.

why does it matter? also, more compact output file is -- better.

If you like "more compact output file", maybe you prefer 2 spaces indent than 4 spaces indent.
I would suggest that we can change below specification document and tool to 2 spaces.

I guess that another person who created the specification document, might prefer 4 spaces indent because of some reasons.
However providing consistent format as a modularity project might be better.

https://pagure.io/modulemd/blob/master/f/spec.yaml
https://github.com/fedora-modularity/dependency-report/blob/master/modules/ruby/ruby.yaml

This is not something we can influence from MBS - we just use the modulemd library to save modulemd to file. We should file it as a bugreport to modulemd. @psabata what do you think?

Note that my intention here is to close this issue in MBS issue tracker and either move it to modulemd issue tracker or just decide it is not a problem. I will keep it open for now to hold the discussion here in single place.

Guys, seriously?

The number of spaces is irrelevant is completely up to the author of the original modulemd file. The input file may or may not be generated while the output in the repo is always [re]generated. If you generate your input with modulemd, you will be able to diff the two quite easily. if you write it manually or generate it with other tools, you most likely won't.

Just like the YAML specification, we don't recommend any particular style. Also if you really need diffs (and I don't really see what you would be using those for other than to satisfy some initial curiosity), compare the structured data rather than the output text stream.

And before I close this ticket:

  • the input is a single input recipe
  • the output is a modified multidocument containing definitions for all modules in the repo
  • the output formatting is undefined, YAML implementation-dependent and can change anytime
  • remember YAML is structured data and handle it that way; you will be fine

Metadata Update from @psabata:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/mbs/issues/658

Please continue any further discussion there.
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.