I think we could easily reference external plugins with a readme type doc instead of a script to start out with. That way there's visibility, but they reference their own home for larger pluigins. We'd do this for quickstart for example.
On Fri, 14 Feb 2014, Kapil Thangavelu wrote: > I think it really depends on how big the plugins are.. most of the ones in > that repo are of the single page variety. i've got several plugins which > are a bit on the larger side (half-dozen to a dozen files) and benefit from > their own repo (bug tracking, etc). Ideally we could just have a page in > the docs that people could submit pull requests for as new plugins emerge. > re centralized plugin management, seems a bit down the road, juju plugins > can be written in any language, while sublime tended to gravitate towards > python for plugins. > > -k > > > > On Fri, Feb 14, 2014 at 7:31 AM, Joshua Strobl <truthfroml...@gmail.com>wrote: > > > Have multiple repositories for the plugins is just unnecessary > > fragmentation (at least at this point). If someone wants to maintain > > their own plugins, they can easily fork the project, add their plugin > > (setting their fork as master and the juju/plugins as upstream) and > > simply do a pull request to get it merged the plugin merged. > > > > In terms of having an index to "register" plugins, you could argue that > > the GitHub repo is for that, given the person "registers" the plugin by > > a pull request and having it be accepted upstream (juju/plugins). > > > > I can agree that we should have some sort of webpage (at > > jujuplugins.com) that lists the plugins (as well as their description, > > required and optional commands or arguments, etc), but that isn't needed > > at this point and we should only cross that bridge when we really need > > to. (It should be noted that the page can still leverage GitHub via > > their APIs, so we won't have to manually add plugins to the site.) > > > > > Sublime Text and Homebrew (if I remember right) does that. > > > > I think you are referring to https://sublime.wbond.net/, which is an > > unofficial repository of Sublime Text plugins, and while I totally > > understand your point about having the multi-repo in the case of Sublime > > Text plugins (and it absolutely makes sense in that environment), it > > should be noted that it isn't possible to accomplish having all of a > > Sublime Text plugin within a single file (from my not-so-immense > > understanding of SL plugin dev), unlike Juju Plugins where it is simply > > something written in a single bash script, so for Sublime Text plugins > > it is more of a necessity, unless you want to do something like > > DefinitelyTyped - https://github.com/borisyankov/DefinitelyTyped - where > > they divide each definition, in our case plugin, into a separate folder. > > > > But yea, I agree 100% about utilizing jujuplugins.com EVENTUALLY, where > > we do disagree on is how we should keep Juju Plugins organized and > > reduce fragmentation (while trying to ensure the plugins remain > > up-to-date) as much as possible. > > > > - Joshua Strobl > > > > On 02/14/2014 01:06 AM, Sebastian wrote: > > > This sounds great!, I was wondering how to extend Juju. > > > > > > When I think about plugins, using Github as a repository seems the right > > > thing, and not just one repository to all. Sublime Text and Homebrew(if I > > > remember right) does that. But definitively we need an index for register > > > them, and not actually for storing the plugin. > > > > > > > > > Abs, > > > Sebas. > > > > > > > > > > > > 2014-02-13 20:58 GMT-02:00 Marco Ceppi <ma...@ondina.co>: > > > > > >> So, when I first started plugins, I was like "WE SHOULD HAVE A WEBSITE, > > >> AND IT SHOULD HAVE PLUGINS, AND AWESOME", but then I realized that we > > don't > > >> have that many plugins. In the future, if plugins become a popular > > thing we > > >> can invest some time in making jujuplugins.com and have a plugin > > >> installer, etc. For now just collecting them all in one place is a good > > >> start. > > >> > > >> Thanks, > > >> Marco Ceppi > > >> > > >> > > >> On Thu, Feb 13, 2014 at 5:50 PM, Joshua Strobl <truthfroml...@gmail.com > > >wrote: > > >> > > >>> Would it be feasible and/or benefitial to have some sort of rating > > >>> system for the plugins, with those that get the most support being > > >>> merged into juju-core (assuming there wouldn't be some upcoming > > >>> functionality that would make the plugin no-longer-useful)? I see that > > >>> as a great way to improve Juju's core functionality gradually without > > >>> having to worry about tackling a possible issue later where plugin X > > >>> that could've been merged is now out-of-date. > > >>> > > >>> On 02/13/2014 11:37 PM, Jorge O. Castro wrote: > > >>>> If you didn't know, Juju has support for plugins. So far these have > > >>>> been scattered over junk branches and pastebins so we're going to > > >>>> organize them so people have one place to find them: > > >>>> > > >>>> https://github.com/juju/plugins > > >>>> > > >>>> We're not going to package them (yet) so we can put them in one place > > >>>> and see which ones are useful and which ones aren't. If you have a > > >>>> Juju plugin you're using and want to share it then please submit it. > > >>>> Thanks to Marco Ceppi for organizing this! > > >>>> > > >>> > > >>> -- > > >>> Juju mailing list > > >>> Juju@lists.ubuntu.com > > >>> Modify settings or unsubscribe at: > > >>> https://lists.ubuntu.com/mailman/listinfo/juju > > >>> > > >> > > >> > > >> -- > > >> Juju mailing list > > >> Juju@lists.ubuntu.com > > >> Modify settings or unsubscribe at: > > >> https://lists.ubuntu.com/mailman/listinfo/juju > > >> > > >> > > > > > > > -- > > Juju mailing list > > Juju@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
