<div dir="ltr"><div>Hi Thomas</div><div><br></div>Thanks for replying so quickly! Answering inline. :)<div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 16, 2016 at 8:56 PM, Thomas Voß <span dir="ltr"><<a href="mailto:thomas.voss@canonical.com" target="_blank">thomas.voss@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Alexey,<br>
<br>
first of all: Thanks for reaching out :) And to answer your final<br>
question first: Snap'ing up applications that feature<br>
a runtime extension mechanism is certainly possible, complexity<br>
depends on the actual application, though.<br>
<br>
To get you started fast: devmode (see<br>
<a href="http://askubuntu.com/questions/783945/what-is-devmode-for-snaps" rel="noreferrer" target="_blank">http://askubuntu.com/<wbr>questions/783945/what-is-<wbr>devmode-for-snaps</a>)<br>
should help to get you off the ground.<br></blockquote><div><br></div><div>Yes, thanks, I know about dev mode, of course running the app in dev mode just makes it work the same, as it would work without using snap, right?.</div><div>I can also run my application from the mounted snap volume directly, with the same result. Of course this works.</div><div><br></div><div>However, I suppose that this is not really the idea behind snap?</div><div>Or is it one of the standard / expected use cases on the end users side, to install from snap, but run directly?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also note that we are right now snap'ing our Unity8 scopes and dash<br>
infrastructure. In a sense, our scopes are an example of a<br>
really complex plugin system and we are likely facing very similar problems.<br></blockquote><div><br></div><div>Well, yeah, perhaps, but in your case, as far as I understand, you can either build snaps for all of the scopes, or force the scope developers to do that.</div><div>I can't have this luxury. Please, see below for more answers and more questions :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'll ask specific questions inline.<br>
<span class=""><br>
On Tue, Aug 16, 2016 at 8:08 PM, Alexey Yakovenko <<a href="mailto:wakeroid@gmail.com">wakeroid@gmail.com</a>> wrote:<br>
> Hi<br>
><br>
> (Before I start, I'd like to apologise if this message has duplicates, I<br>
> messed up with the mailing list subscription at first).<br>
><br>
> Many users are requesting snap package format for my music player<br>
> application.<br>
><br>
> I researched this topic, and came up with a list of problems which I could<br>
> not solve from documentation or google searches.<br>
><br>
> So here's a short introduction to my app architecture:<br>
><br>
> * The main module, which is a console application, which can load and use<br>
> plugins of various kinds<br>
<br>
</span>Is your application using an in- or out-of-process plugin architecture?<br></blockquote><div><br></div><div>In-process.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> * A set of standard plugins, which can link to certain libraries<br>
>     * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various input<br>
> plugins, etc<br>
<br>
</span>Do you maintain those plugins in-tree? Would you be fine with<br>
distributing them within your application's snap?<br>
Or would you rather prefer to distribute them as separate snaps, with<br>
you being the publisher?<br></blockquote><div><br></div><div>They are 3rd party projects, most often developed and distributed without my knowledge -- i.e. 100% third party.</div><div>They can be released a few years after my application ships.</div><div>Most of the time, they are also binary-compatible with multiple versions of the host application.</div><div>There's a ton of plugins which can run on any version of the host app, released in the last 5 years.</div><div>Even if I wanted to make snaps for each of them, I would not have resources to do that.</div><div>So I can't really answer positively to any of the 2 questions.</div><div>The plugins are just *.so files, sometimes with extra data files, which need to be dropped to ~/.local/lib/appname (that's when not using snap).</div><div><br></div><div>Of course, the standard plugins which I ship with the host application don't have any problems, I think they would "just work".</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> * External plugins, which a user may download from internet -- they can be<br>
> anything, for example a plugin could implement a UI in Qt4 or Qt5, or<br>
> ncurses, or play sound via Jack.<br>
<br>
</span>Is the download and installation handled by your application or with<br>
the help of the underlying packaging system?<br></blockquote><div><br></div><div>Neither. Usually a user downloads a zip file from a plugin developer's website, and unpacks it into ~/.local/lib/appname.</div><div>If there are no binary builds available, a user has to compile the plugin by himself. Many developers are providing shell scripts to compile and install, or full featured build systems using Make etc.</div><div><br></div><div>Unfortunately, neither the host application, nor the plugins, are available in most linux distribution package systems.</div><div>This is what's making snap particularly interesting (if it can do what's needed).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As to what degree do you "trust" those plugins and their authors?<br></blockquote><div><br></div><div>I don't know most of them.</div><div>There are a few developers who I have contact with, but technically I can't trust any of them.</div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would you be fine to publish them as well?<br></blockquote><div><br></div><div>I'm already publishing a bunch of the 3rd party plugins, but I can't publish all of them for many reasons.</div><div>There are simply too many of these projects. I can't even keep track of them.</div><div>Basically, people release new ones almost weekly.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
>     * It is not known at the time of package creation, what these packages<br>
> could be.<br>
><br>
> So when I'm creating the package, I have a problem -- which UI toolkit to<br>
> use, if my app supports any toolkit? It ships with GTK2 and GTK3, but there<br>
> are external plugins which add more toolkits. I can't really predict which<br>
> toolkit the user wants, and what libraries the plugins will use -- it can be<br>
> Qt4 or 5, or ncurses, or anything really.<br>
><br>
<br>
</span>I'm trying to rephrase a little: Your application supports plugins<br>
which may use *any* toolkit<br>
as long as the plugin bundles the respective runtime dependencies<br>
correctly. So it is ultimately the<br>
responsibility of the plugin to provide all the required libraries.<br></blockquote><div><br></div><div>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?</div><div>But still, each of the plugin developers would have to provide each of their plugins in snap packages?</div><div>The problem is that I can't make them do that. I don't have communication with them.</div><div>Some developers build a plugin, make a .so out of it, put this on their website, and forget about it forever.</div><div>So we sometimes have only this .so file, without source code even.</div><div><br></div><div>What is also important: a user might already have a bunch of plugins installed on his computer, and he would obviously want or need to keep them, so if he can't use them with deadbeef from Snap -- he would not be using deadbeef from snap at all, and stick with another installation method (one of the existing ones).</div><div><br></div><div>A more complex question that I couldn't find an answer too:</div><div>How to make a snap, which can use both GTK2 and GTK3.</div><div><br></div><div>To simplify the discussion, let's say I have 2 executable files, app_gtk2, and app_gtk3. They ship in the same snap.</div><div>Is it possible to do this, so that either of the 2 apps can be used from within the same snap package?</div><div><br></div><div>So what I described above is a simplified version.</div><div><br></div><div>What I really have: there's only 1 executable file, but it can load either a GTK2 plugin (ui_gtk2.so), or a GTK3 plugin (ui_gtk3.so), depending on the configuration and command line options.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> Another problem. Let's take the jack output plugin as an example..<br>
><br>
> If the user downloads jack.so (the plugin), and puts it in the folder, the<br>
> player won't be able to load it, because the jack client library is not a<br>
> part of snap, or because there's no access to jack server, or something like<br>
> that, correct?<br>
><br>
<br>
</span>The answer depends on how your application handles plugin download &<br>
installation.<br>
The issues would be solved if plugins were snaps. In that case, the<br>
individual plugin brings<br>
along its dependencies and defines the interfaces it would like to use<br>
(see [1] for an excellent introduction & overview to<br>
Snappy interfaces).<br></blockquote><div><br></div><div>Application itself doesn't manage plugin download & installation at all.</div><div>It can load and run the plugins which are already downloaded and present in one of the pre-defined folders.</div><div><br></div><div>There's no central registry of all plugins, therefore it's not really possible to change this easily.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> So, the final question.. Is it just a terrible idea to use snap for this<br>
> kind of applications? Or am I misunderstanding something, and all of this is<br>
> possible?<br>
><br>
> I really hope to get some useful "official" answers, which I could forward<br>
> to the users which request snap packages :)<br>
><br>
<br>
</span>Looking forward to your answers and to dive deeper in your specific case.<br>
<br>
Cheers,<br>
<br>
  Thomas<br>
<br>
P.S.: Feel free to reach out on irc(#snappy@freenode), too.<br></blockquote><div><br></div><div>Sure, let's see the outcome of this round of questions, and then we can see if it's worth to continue.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html" rel="noreferrer" target="_blank">http://www.zygoon.pl/2016/08/<wbr>creating-your-first-snappy-<wbr>interface.html</a><br>
<br>
> Best regards.<br>
<span class=""><font color="#888888">><br>
> --<br>
> Snapcraft mailing list<br>
> <a href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/snapcraft</a><br>
><br>
</font></span></blockquote></div><br></div></div></div>