We’ve been discussing the appstream ID field for the last three sprints and @apol is now blocked on that, so let’s see if we can reach some agreement about the best way to support the feature and then push it forward.
For some background, the main requirement is being able to identify an application across multiple possible sources, and potentially multiple packaging formats as well. The main contender for this right now is the appstream ID, which is a format-agnostic way to provide metadata and that has been adopted in many repositories.
Past discussions proposed having an ID field in an appstream.yaml file next to snap.yaml, or in an appstream: field inside snap.yaml. The first proposal assumed that there would be many fields which were appstream specific, but after many conversations all fields we discussed are first-class metadata that should eventually make their way into the format itself, so we don’t want to duplicate it into a second file. The second proposal already acknowledges that and proposes importing the data into snap.yaml and snapcraft.yaml proper, while still labeling it under an appstream domain. It also incorporated a lesson we learned later: we need to be able to to associate the ID with an application rather than the whole snap, as some of the metadata is application-specific (desktop files, etc).
So, here is a strawman that takes the second proposal one step further: how about having an id field in the application block itself:
apps: myapp: id: com.example.myapp command: run-myapp
The field would be optional, and would be automatically populated if information is imported from an appstream file in a way that can be automatically inferred. For example, we can compare binary name, package name, etc, with the application name in snapcraft.yaml. In addition to the application ID, similar logic might be used for the desktop file, icons, etc.
What do you think?