List plugins installed?
Tim Penhey
tim.penhey at canonical.com
Thu Sep 29 22:19:05 UTC 2016
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 <tim.penhey at canonical.com
> <mailto:tim.penhey at canonical.com>> 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
> <stuart.bishop at canonical.com <mailto:stuart.bishop at canonical.com>
> > <mailto: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>
> <mailto: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>
> <mailto: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>
> > <mailto: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>
> <mailto: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
> >
> >
> >
>
> --
> 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
>
More information about the Juju-dev
mailing list