Add short output

[schuellerf]

Add short output
which looks like

rhel-9.5:
  ami: [ aarch64, x86_64 ]
  azure-rhui: [ aarch64, x86_64 ]
  azure-sap-rhui: [ x86_64 ]
  ec2: [ aarch64, x86_64 ]
…
rhel-9.6:
  ami: [ aarch64, x86_64 ]
  azure-rhui: [ aarch64, x86_64 ]
  azure-sap-rhui: [ x86_64 ]
  ec2: [ aarch64, x86_64 ]
  ec2-ha: [ x86_64 ]
  ec2-sap: [ x86_64 ]

(this is based on #1166 )

[mvo5]

This is an interesting idea, what if we would make it valid yaml so that it would look nice but still be (relatively) easy to parse? How would that look like? Note that I don't think we need a fully yaml parser/struct here (at least initially) to test the idea, just re-structuing the output that its a valid yaml map if distroname that then has keys with type and a list of arches (which is super close to what is written here already). Wdyt?

[schuellerf]

I added a colon after the distro, so now technically it's yaml but the arches are no list :-/
I'll think about it if making this a valid yaml list hurts readability too much…

[schuellerf]

Thank you @mvo5 for your hint, it seems possible to have this a valid yaml.
I updated the description accordingly, please check.

The structure does not make too much sense, I guess (to nest distro -> type -> arch) but still you can parse it if needed and it's well readable which is the main goal of this output format.

[schuellerf]

btw I tested the output with:

./bin/image-builder list-images --output short | yq -P .

[supakeen]

Thank you.

Some remarks but non-blocking:

• Should we instead call this yaml if we're committed to making it YAML?
• In that case, should we 'just' have a proper yaml encoder just like json?

I don't particularly like the spellcheck commit showing up in this PR but if it blocks CI otherwise, I guess.

[schuellerf]

For yaml you would probably expect the data structure to be the same as for json (just being a list of "objects").
In this case the main use case is really to get a short output. But if we decide otherwise or want yaml additionally, I'd be happy to implement in a followup PR 👌

[mvo5]

Fwiw, I think this got merged a bit too quickly, I think there are still open questions like how exactly this should look like (and I would have liked to review the new implementation too). There is also the open question of how this relates to https://github.com/osbuild/osbuild-composer/pull/4336/files#diff-792fae8eca7351040416f58a710aa554fe76d91e6f39cfbe122bf85428f34afdR572 - which is similar but slightly different which is now confusing for users of our API.

[schuellerf]

Sorry, I thought all your remarks have been addressed :-/
We can for sure align here and I'll do a followup!