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.bis...@canonical.com> wrote: > On 28 September 2016 at 22:45, roger peppe <roger.pe...@canonical.com> > wrote: > >> On 28 September 2016 at 14:55, Rick Harding <rick.hard...@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.bis...@canonical.com> > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju