Using snap for application with plugins

[Stuart Bishop]

On 19 August 2016 at 20:39, Thomas Voß <thomas.voss at canonical.com> wrote:


> Now that triggers a question for me: How do end users resolve
> dependencies of plugins today?
> Do they just assume that the downloaded plugins bring along whatever
> they need? Or do they rely
> on the package manager to resolve dependencies ad hoc?
>
> In any case: It seems to me that shipping your application and its
> core plugins as a snap is certainly possible.
> For installing 3rd party plugins: Why not have an "app" or command on
> your snap that takes care of copying files and folders
> to the right place in the writable parts of the snap. I'm thinking
> along the lines of:
>
>   yourapp.install-plugin /path/to/file/or/folder
>
> That would also help your users in that they don't need to know about
> a specific directory to place plugins into.
>
>
I'm interested in using Juju plugins with the new Juju snap.

With a packaged installation, users run a command 'juju foo' or
'../1.29.3/juju foo' which calls a juju executable. juju then executes
'juju-foo' from $PATH, with a modified environment ($PATH gets prepended to
ensure the correct version of juju and tools is found by the plugin). The
juju-foo plugin does its thing, usually needing to invoke the original juju
executable.

Plugins are often quick hacks and not distributed. They cannot all be
distributed in the juju snap.

Plugins often come with their own set of dependencies, such as Python
libraries or calling tools such as graphviz. They are not a compiled .so or
.zip file.

So juju snap needs to invoke plugins, outside of its containment, and these
plugins need to call back to juju (ie. stay devmode). Or the plugins and
all their dependencies need to be brought inside juju's containment.

To run with your suggestion, would the juju snap need to provide a way to
install other snaps inside its containment? Is that possible?

Or should this be standard in snapd, being able to merge snaps into
existing snaps extending its containment and modifying its behaviour
(similar to juju subordinate charms)?

Or is there a simpler way?

I think the goal here is meet or exceed the functionality of the existing
package installations. Snaps are going to be a hard sell to people who have
grown used to dumping a shell script in their $PATH to enhance usability.

git plugins are very similar, so it isn't just a juju problem.



> Access to common shared directories in the user's home directory is
> possible.
> I think that should solve the problem of supporting old plugin
> installations.
>

This approach doesn't work when plugins need to reinvoke juju or call
/snap/bin/graphviz. But if, in addition to home, we had an interface that
allowed calling executables in /snap/bin it could work.



-- 
Stuart Bishop <stuart.bishop at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160824/dec4b328/attachment.html>