Sharing is caring, with Snaps!

Posted by: Michael Hall 7 years, 7 months ago

(Comments)

Snaps are a great way to get the most up to date applications on your desktop without putting the security or stability or your system at risk. I’ve been snapping up a bunch of things lately and the potential this new paradigm offers is going to be revolutionary. Unfortunately nothing comes for free, and the security of snaps comes with some necessary tradeoffs like isolation and confinement, which reduces some of the power and flexibility we’ve become used to as Linux users.

But now the developers of the snappy system (snapd, snap-confine and snapcraft) are giving us back some of that missing flexibility in the form of a new “content” interface which allows you to share files (executables, libraries, or data) between the snap packages that you develop. I decided to take this new interface for a test drive using one of the applications I had recently snapped: Geany, my editor of choice. Geany has the ability to load plugins to extend it’s functionality, and infact has a set of plugins available in a separate Github repository from the application itself.

I already had a working snap for Geany, so the next thing I had to do was create a snap for the plugins. Like Geany itself, the plugins are hosted on GitHub and have a nice build configuration already, so turning it into a snap was pretty trivial. I used the autotools plugin in Snapcraft to pull the git source and build all of the available plugins. Because my Geany snap was built with Gtk+ 3, I had to build the plugins for the same toolkit, but other than that I didn’t have to do anything special.

parts:
 all-plugins:
 plugin: autotools
 source: git@github.com:geany/geany-plugins.git
 source-type: git
 configflags: [--enable-gtk3=yes --enable-all-plugins]

Now that I had a geany.snap and geany-plugins.snap, the next step was to get them working together. Specifically I wanted Geany to be able to see and load the plugin files from the plugins snap, so it was really just a one-way sharing. To do this I had to create both a slot and a plug using the content interface. Usually when you’re building snap you only use plugs, such as network or x11, because you are consuming services provided by the core OS. In those cases also you just have to provide the interface name in the list of plugs, because the interface and the plug have the same name.

But with the content interface you need to do more than that. Because different snaps will provide different content, and a single snap can provide multiple kinds of content, you have to define a new name that is specific to what content you are sharing. So in my geany-plugins snapcraft.yaml I defined a new kind of content that I called geany-plugins-all (because it contains all the geany plugins in the snap), and I put that into a slot called geany-plugins-slot which is how we will refer to it later. I told snapcraft that this new slot was using the content interface, and then finally told it what content to share across that interface, which for geany-plugins was the entire snap’s content.

slots:
 geany-plugins-slot:
 content: geany-plugins-all
 interface: content
 read:
 - /

With that I had one half of the content interface defined. I had a geany-plugins.snap that was able to share all of it’s content with another snap. The next step was to implement the plug half of the interface in my existing geany.snap. This time instead of using a slots: section I would define a plugs: section, with a new plug named geany-plugins-plug and again specifying the interface to be content just like in the slot. Here again I had to specify the content by name, which had to match the geany-plugins-all that was used in the slot. The names of the plug and slot are only relevant to the user who needs to connect them, it’s this content name that snapd uses to make sure they can be connected in the first place. Finally I had to give the plug a target directory for where the shared content will be put. I chose a directory called plugins, and when the snaps are connected the geany-plugins.snap content will be bind-mounted into this directory in the geany.snap

plugs:
 geany-plugins-plug:
 content: geany-plugins-all
 default-provider: geany-plugins
 interface: content
 target: plugins

Lastly I needed to tell snapcraft which app would use this interface. Since the Geany snap only has one, I added it there.

apps:
 geany:
 command: gtk-launch geany
 plugs: [x11, unity7, home, geany-plugins-plug]

Once the snaps were built, I could install them and the new plug and slot were automatically connected

$ snap interfaces
Slot                             Plug
geany-plugins:geany-plugins-slot geany:geany-plugins-plug

Now that put the plugins into the application’s snap space, but it wasn’t enough for Geany to actually find them. To do that I used Geany’s Extra plugin path preferences to point it to the location of the shared plugin files.

After doing that, I could open the Plugin manager and see all of the newly shared plugins. Not all of them work, and some assume specific install locations or access to other parts of the filesystem that they won’t have being in a snap. The Geany developers warned me about that, but the ones I really wanted appear to work.

• ← My day of convergence
• Desktop app snap in 300KB →