Using snap for application with plugins

[Alexey Yakovenko]

Hi Thomas, and sorry for the duplicate message, at first I replied
privately instead of posting to the list


> >>
> >> As to what degree do you "trust" those plugins and their authors?
> >
> >
> > I don't know most of them.
> > There are a few developers who I have contact with, but technically I
> can't
> > trust any of them.
> > It's completely up to the end user whether to install certain plugin, or
> not
> > -- the same way as he would install an application downloaded from the
> > internet.
> >
>
> 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?
>

When the users download binaries, they usually only rely on the "system"
libraries, like GTK, GLIBC, etc, and statically link everything else.

However, many plugins require certain libraries to be installed in the
system, and won't load otherwise.
Of course, these plugins only dynamically link to the libraries with stable
API and which support backwards compatibility.

Example being the plugin for supporting Jack, or Qt.

I'm not aware of any popular linux distributions, that ship my application
or its plugins, so there's no answer to the package manager question.


>
> In any case: It seems to me that shipping your application and its
> core plugins as a snap is certainly possible.
>

Yes, I mentioned in one of the previous conversations, that this part works
fine.



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

Yes, I think we figured out that part already in the previous round (or
maybe I figured this out by talking with someone else).

However, the plugins won't be able to access the libraries from within
sandbox, so they won't work.

As far as I understand, the way to solve this would be to package such
plugins as snap packages.

However, at this time I don't know how to make the host application find
those plugins (i.e. how to enumerate any external plugins installed via
snap).



>
> That would also help your users in that they don't need to know about
> a specific directory to place plugins into.
>

That's more a usability problem, than a technical one.
And yes, I agree that usability can be improved this way.
But that won't make the plugins work :)



> > Yeah, so the answer is "a plugin which is using Qt5 could work, but it
> would
> > need to be in snap package, and has to ship its own version of Qt5" as an
> > example?
>
> Yup, but that comes back to my question: How are dependencies for the
> plugins
> handled today?
>

They are not handled in any way. Basically, you download a plugin, and you
need to make sure that e.g. Qt is installed.
If Qt is not installed -- dlopen would fail, and the plugin would be
ignored.


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

OK, that's good to know. I couldn't make this work, but I think I needed to
update my Ubuntu installation.


Anyway, I think that I have enough information for now.

Thanks for all the responses, and best regards!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160819/4ddc98a6/attachment.html>