List plugins installed?

[Tim Penhey]

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 meta-data file.

Tim

On 30/09/16 10:47, Nate Finch wrote:
> Seem alike the easiest thing to do is have a designated plugin directory
> and have juju install <path/to/plugin> 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 <stuart.bishop at canonical.com
> <mailto:stuart.bishop at canonical.com>> wrote:
>
>     On 28 September 2016 at 22:45, roger peppe
>     <roger.peppe at canonical.com <mailto:roger.peppe at canonical.com>> wrote:
>
>         On 28 September 2016 at 14:55, Rick Harding
>         <rick.harding at canonical.com <mailto:rick.harding at canonical.com>>
>         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 means that plugins
>         > becomes a noun in our language.
>         >
>         > What's interesting is that add/remove fall out because that
>         > installing/uninstalling. I think that show-plugin might be interesting to
>         > auto run the --description flag to bring it into CLI alignment with the new
>         > world order.
>
>         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 plugin until you explicitly
>         name it).
>
>         Perhaps there could be a standard way for a plugin to provide
>         metadata about itself as a data file.
>
>
>     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.
>
>
>     --
>     Stuart Bishop <stuart.bishop at canonical.com
>     <mailto:stuart.bishop at canonical.com>>
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>