Thanks Marco. Would be good to have something solid to drive the plug-in changes with.
Tim On 30/09/16 11:16, Marco Ceppi wrote:
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 <[email protected] <mailto:[email protected]>> wrote: 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 <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > On 28 September 2016 at 22:45, roger peppe > <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: > > On 28 September 2016 at 14:55, Rick Harding > <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > 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 <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > -- > Juju-dev mailing list > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- Juju-dev mailing list [email protected] <mailto:[email protected]> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
