In an effort to have a clearer way to express common patterns and reduce repetition, we’re proposing the introduction of the templates property. This is a root property as well as a per-app property (root templates apply to apps that do not declare a template).
In a general sense, templates manipulate the YAML within the snapcraft.yaml, but only in a way that is expressible as a plain snapcraft.yaml. For example, they can add new parts, add a minimum set of plugs to apps, etc.
Say a gtk3 template was supported. The way a user might specify that a given app is a gtk3 app would look like this:
What sort of modifications do you envision allowing a template to make?
I am a little concerned about having the templates maintained in the snapcraft source tree though: it’s going to increase the turnaround time for bug fixes, particularly if I’m using Launchpad/build.snapcraft.io to build my snaps and don’t have direct control over the snapcraft version. Do you think it’d be possible to specify templates as data? Making these as easy to distribute as cloud parts would be a big plus.
Off the top of my head, here are a few things I think would be good candidates for templates:
Defining standard content interface plugs: themes are the main one here, where we’re looking at a significant amount of boilerplate to correctly plug in to the gtk-common-themes snap (plus whatever other third party theme snaps we might get in future). These plugs need to be declared at the top level.
Maybe for cache generation? We’ve previously talked about wanting to pre-generate gsettings, icon theme, etc. The last suggestion for this was a global pre-pack scriptlet, which couldn’t really be introduced by a cloud part. Maybe that scriptlet would be more usable if introduced by a template?