Who can write snapcraft extensions?

snapcraft
1

I’ve found there is a lot of repetition in the snaps I’m working on (e.g. to do with setting up the graphics stack for IoT). Some of this can be addressed by including stage-snaps, but there remain interfaces, environment variables and command-chain options that need to be cut & paste each time.

That sounds like a job for snapcraft extensions. But is there a way pull in user-written extensions locally? (I anticipate quite a bit of “churn” as I try retrofitting across different snaps.) Is it necessary to have them accepted into the snapcraft project and, if so, what’s are the criteria for inclusion?

2 Likes
2

I’ll exhume this and ask the developers again: Will it ever be possible to include local extensions? There are local plugins, so someone saw the need for those too. Local/out of tree extensions could be collected/published somewhere on the forum and enable a flourishing development community like e.g. on GitHub Actions.

3

We used to have something called wiki-parts which were something like this. One of the goals of extensions was to have a controlled environment where changes would take place, we can of course revisit that.

1 Like
4

Ah, you’re referring to https://snapcraft.io/docs/remote-reusable-parts. That was very “copy-pasty”, I guess.

I’m thinking more like shipping a python file with a class inheriting from Extension in snapcraft.internal.project_loader._extensions. Snapcraft would load this from snap/extensions. Installing such extensions would be a matter of adding a git submodule.

5

If you don’t mind the extra step of compiling the yaml from jsonnet, I wrote a simple wrapper app that can be used with jsonnet files to formulate a snapcraft.yaml based on a reusable approach. See https://sc-jsonnet.readthedocs.io/en/latest/ for the app, and https://snapcraft-utils-library.readthedocs.io/en/latest/ and https://snapcraft-alsa.readthedocs.io/en/latest/ for the libraries/extensions that I have written for it so far…

This is what a jsonnet file can look like for an app:

1 Like
6

Yes, I’ve seen this before, and it looks very useful. Chaining tools to do the job is very classic Unix philosophy for me.

I’m just saying that many successful platforms have embraced the plugin/store pattern, and it gets the momentum going like nothing else. See GitHub Actions, see Visual Studio Code, see FreeCAD (Python workbenches, a stroke of genius!), OBS Studio… So if we have a properly designed extension API already, which remains somewhat stable (and is versioned, like plugins are), enabling loadable extensions seems like a logical step.

2 Likes