Convert xml to yml doesn't preserve artifacts information

[CarlSchwan]

Hi, I added artifacts information to the Krita AppStream file: https://invent.kde.org/kde/krita/-/merge_requests/295/diffs.

But when converting the XML AppStream file to YAML using appstreamcli convert, this information is removed.

Releases:
- version: 4.2.9.0
  type: stable
  unix-timestamp: 1585180800
  url:
    details: https://krita.org/en/item/krita-4-2-9-released/
- version: 4.2.8.0
  type: stable
  unix-timestamp: 1574812800
  url:
    details: https://krita.org/en/item/krita-4-2-8-released/
- version: 4.2.7.1
  type: stable
  unix-timestamp: 1552176000
  url:
    details: https://krita.org/en/item/krita-4-2-7-released/

The file is converted when building kde.org/applications, I didn't write the extractor but I guess the reason we convert the file is that it is easier to load a YAML file. This could be changed to load the XML file directly but I prefer not touching a working system without good reasons :-)

appstreamcli --version
AppStream version: 0.12.10

[ximion]

The reason for that is that DEP-11 (the YAML representation) doesn't use artifacts, so they are not included since they aren't used by distributions to install software.
However, apparently we have a user of this feature now, so maybe it makes sense to add it if it's useful for KDE :-)
I'll have a look.
Does KDE really use appstreamcli convert or do you actually have an appstream-generator instance running somewhere to produce this data?

[CarlSchwan]

Yes we use appstreamcli convert in https://invent.kde.org/websites/kde-org-applications-extractor/-/blob/master/lib/app_data.rb

[ximion]

@ognarb You should really use libappstream directly, maybe via GObject-Introspection. AFAIK Ruby also supports that pretty well.

But there isn't a compelling reason why there shouldn't be a YAML representation of release artifaczs (other than this being extra work). So, here you go ;-)

[CarlSchwan]

Thanks for adding this feature :D and yeah we should use libappstream directly but probably not soon. The current system while not optimal still works fine for our use case and I don't have the time to rewrite it.