Proposal: templates

snapcraft
1

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:

# <snip metadata>

apps:
  my-app:
    command: run-my-app
    templates: [gtk3]

# <snip parts>

With that, the snapcraft CLI knows two things need to happen:

  1. The gtk3 template will need to be built and installed into the snap like any other part.
  2. The gtk3 template will need to add a YAML snippet to the app definition (for example, gtk3 might add the x11 plug, and may also need to add an item to the command chain).

The snapcraft CLI will also need to grow a new command for displaying the exploded snapcraft.yaml (i.e. with templates applied) for education of what exactly the template does.

1 Like
2

Where are the template definitions maintained? Are they per-snap, or is there a central repository somewhere? How are templates discovered? How are they versioned?

3

They will be part of the snapcraft CLI, maintained in its codebase.

Good question! We have a command to list and get more information about plugins, we should have something similar for templates.

It is our hope that, if we can keep templates lean, mean, fine-grained and doing the bare minimum, we don’t need versioning.

4

So a framework for building snaps? Kinda reminds me of Angular design. The templates could be discovered trough some npm style dep manager.

5

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:

  1. 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.

  2. 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?

3 Likes