<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 September 2016 at 22:45, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 September 2016 at 14:55, Rick Harding <<a href="mailto:rick.harding@canonical.com">rick.harding@canonical.com</a>> wrote:<br>
> This is just a miss. The original ability to see the plugins was a subset of<br>
> the help command and didn't make our CLI spreadsheet for things to rework. I<br>
> agree that list-plugins is the right idea here and that means that plugins<br>
> becomes a noun in our language.<br>
><br>
> What's interesting is that add/remove fall out because that<br>
> installing/uninstalling. I think that show-plugin might be interesting to<br>
> auto run the --description flag to bring it into CLI alignment with the new<br>
> world order.<br>
<br>
</span>I've voiced discomfort with this before - I don't think that we should<br>
arbitrarily run all executables that happen to have a "juju-" prefix.<br>
It's potentially dangerous (for example, note that although git relies heavily<br>
on plugins, it doesn't execute a plugin until you explicitly name it).<br>
<br>
Perhaps there could be a standard way for a plugin to provide<br>
metadata about itself as a data file.<br>
<br></blockquote><div><br></div><div>It also might be time to work out how a Juju snap is going to call or install plugins. I don't think the existing design is going to work, and there is still time to flag it as deprecated in the changelogs for 2.0 and work out the way forward for 2.1.<br></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>