<div dir="ltr">On 19 August 2016 at 20:39, Thomas Voß <span dir="ltr"><<a href="mailto:thomas.voss@canonical.com" target="_blank">thomas.voss@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now that triggers a question for me: How do end users resolve<br>
dependencies of plugins today?<br>
Do they just assume that the downloaded plugins bring along whatever<br>
they need? Or do they rely<br>
on the package manager to resolve dependencies ad hoc?<br>
<br>
In any case: It seems to me that shipping your application and its<br>
core plugins as a snap is certainly possible.<br>
For installing 3rd party plugins: Why not have an "app" or command on<br>
your snap that takes care of copying files and folders<br>
to the right place in the writable parts of the snap. I'm thinking<br>
along the lines of:<br>
<br>
  yourapp.install-plugin /path/to/file/or/folder<br>
<br>
That would also help your users in that they don't need to know about<br>
a specific directory to place plugins into.<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>I'm interested in using Juju plugins with the new Juju snap.<br><br></div><div>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.<br><br></div><div>Plugins are often quick hacks and not distributed. They cannot all be distributed in the juju snap.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>To run with your suggestion, would the juju snap need to provide a way to install other snaps inside its containment? Is that possible?<br><br></div><div>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)?<br><br></div><div>Or is there a simpler way? <br><br></div><div>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.<br></div><div><br></div><div>git plugins are very similar, so it isn't just a juju problem.<br></div><div><br> <span class=""></span><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Access to common shared directories in the user's home directory is possible.<br>
I think that should solve the problem of supporting old plugin installations.<br></blockquote><div><br></div><div>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.<br></div><div class="h5"> <br clear="all"></div></div><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></div>
</div></div>