Using snap for application with plugins

Thomas Voß thomas.voss at
Tue Aug 16 18:56:30 UTC 2016

Hey Alexey,

first of all: Thanks for reaching out :) And to answer your final
question first: Snap'ing up applications that feature
a runtime extension mechanism is certainly possible, complexity
depends on the actual application, though.

To get you started fast: devmode (see
should help to get you off the ground.

Also note that we are right now snap'ing our Unity8 scopes and dash
infrastructure. In a sense, our scopes are an example of a
really complex plugin system and we are likely facing very similar problems.

I'll ask specific questions inline.

On Tue, Aug 16, 2016 at 8:08 PM, Alexey Yakovenko <wakeroid at> wrote:
> Hi
> (Before I start, I'd like to apologise if this message has duplicates, I
> messed up with the mailing list subscription at first).
> Many users are requesting snap package format for my music player
> application.
> I researched this topic, and came up with a list of problems which I could
> not solve from documentation or google searches.
> So here's a short introduction to my app architecture:
> * The main module, which is a console application, which can load and use
> plugins of various kinds

Is your application using an in- or out-of-process plugin architecture?

> * A set of standard plugins, which can link to certain libraries
>     * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various input
> plugins, etc

Do you maintain those plugins in-tree? Would you be fine with
distributing them within your application's snap?
Or would you rather prefer to distribute them as separate snaps, with
you being the publisher?

> * External plugins, which a user may download from internet -- they can be
> anything, for example a plugin could implement a UI in Qt4 or Qt5, or
> ncurses, or play sound via Jack.

Is the download and installation handled by your application or with
the help of the underlying packaging system?
As to what degree do you "trust" those plugins and their authors?
Would you be fine to publish them as well?

>     * It is not known at the time of package creation, what these packages
> could be.
> So when I'm creating the package, I have a problem -- which UI toolkit to
> use, if my app supports any toolkit? It ships with GTK2 and GTK3, but there
> are external plugins which add more toolkits. I can't really predict which
> toolkit the user wants, and what libraries the plugins will use -- it can be
> Qt4 or 5, or ncurses, or anything really.

I'm trying to rephrase a little: Your application supports plugins
which may use *any* toolkit
as long as the plugin bundles the respective runtime dependencies
correctly. So it is ultimately the
responsibility of the plugin to provide all the required libraries.

> Another problem. Let's take the jack output plugin as an example..
> If the user downloads (the plugin), and puts it in the folder, the
> player won't be able to load it, because the jack client library is not a
> part of snap, or because there's no access to jack server, or something like
> that, correct?

The answer depends on how your application handles plugin download &
The issues would be solved if plugins were snaps. In that case, the
individual plugin brings
along its dependencies and defines the interfaces it would like to use
(see [1] for an excellent introduction & overview to
Snappy interfaces).

> So, the final question.. Is it just a terrible idea to use snap for this
> kind of applications? Or am I misunderstanding something, and all of this is
> possible?
> I really hope to get some useful "official" answers, which I could forward
> to the users which request snap packages :)

Looking forward to your answers and to dive deeper in your specific case.



P.S.: Feel free to reach out on irc(#snappy at freenode), too.


> Best regards.
> --
> Snapcraft mailing list
> Snapcraft at
> Modify settings or unsubscribe at:

More information about the Snapcraft mailing list