There has been discussion for a while, such as what can be read about on Development sprint June 26th, 2017, to provide mechanisms to use metadata (I am using the term lightly here) from existing data already used in a given project tree.
Such metadata that is useful is what can be found in projects assets like:
From these assets we can pre-populate data used in a snap such as:
- application icons
- application screenshots
For the case of desktop applications, where there is use of appstream data, it is also interesting to expose the appstream id in some way through store APIs and snap info which would provide the benefit of deduplication capabilities in store fronts such as Gnome Software and KDE’s Discover.
As a proposal on the developer end, snapcraft would implement handlers to consume the metadata from specified locations. These artifacts would be specified within a part’s definition. As a strawman the proposal would be
parts: application_part: source: . plugin: python extract: - setup.py
Where by default, the defined files would be relative to
source. To extract something that is created during the build process it would look like:
parts: application_part: source: . plugin: cmake extract: - $SNAPCRAFT_PART_INSTALL/usr/share/metainfo/libreoffice-writer.appdata.xml
To enable this,
snapcraft would stop enforcing having these consumable metadata items as part of the
snapcraft.yaml and instead check for their existence in the resulting
Additionally, when using an appstream source to extract information,
meta/snap.yaml will add the appstream id, as a working strawman proposal it would look like:
name: cool-application summary: <summary from extracted from the appstream xml> description: <description extracted from the appstream xml> ... ... appstream: id: org.foo.cool-application
Once the snap is avaliable on the store, the details call for the given snap will ad the appstream id into the payload as will the relevant API calls to snapd.
This is a broad scope of the items that would make this feature complete:
- Add handler system for snapcraft to consume metadata.
- Add an appstream handler (as a first candidate) to snapcraft.
- Allow the appstream id data in the review tools.
- Expose the appstream id in the relevant store API calls.
- Expose the appstream id in the relevant snapd API calls.