On 30 September 2016 at 04:47, Nate Finch wrote:
> Seem alike the easiest thing to do is have a designated plugin directory
> and have juju install copy the binary/script there. Then
> we're only running plugins the user has specifically asked to install.
>
This does
Thanks have some ideas about this, I'll file a bug (blueprint?) about it. I
really care about plugins and would like to make them more robust in Juju.
Marco
On Thu, Sep 29, 2016, 6:07 PM Tim Penhey wrote:
> If we do that, then we can make the plug-in also install a
If we do that, then we can make the plug-in also install a metadata file
that explains help and usage, so you don't call the script to do that.
It makes it easy to list plug-ins, because you are searching a known
location, and not the entire path. Only show plug-ins that have the
appropriate
Seem alike the easiest thing to do is have a designated plugin directory
and have juju install copy the binary/script there. Then
we're only running plugins the user has specifically asked to install.
On Thu, Sep 29, 2016, 4:33 AM Stuart Bishop
wrote:
> On 28
On 28/09/16 17:45, roger peppe wrote:
> I've voiced discomfort with this before - I don't think that we should
> arbitrarily run all executables that happen to have a "juju-" prefix.
> It's potentially dangerous (for example, note that although git relies heavily
> on plugins, it doesn't execute a
On 28 September 2016 at 14:55, Rick Harding wrote:
> This is just a miss. The original ability to see the plugins was a subset of
> the help command and didn't make our CLI spreadsheet for things to rework. I
> agree that list-plugins is the right idea here and that
This is just a miss. The original ability to see the plugins was a subset
of the help command and didn't make our CLI spreadsheet for things to
rework. I agree that list-plugins is the right idea here and that means
that plugins becomes a noun in our language.
What's interesting is that