Hi Andrew, I agree on all points. Some additional feedback on a few specifics:
> It looks like Mike has made a start on that with his > cordova-pluginrepo repository Correct! Thanks for taking the time to look at it. I'm hoping to have a working prototype by end of week. > The only way to find those problems is to try writing those plugins. Agreed, though I think inspecting existing plugins is a good start too. Have you had a chance to look at my google docs spreadsheet on plugin work? tab 1 is a grid of all plugins and their supported platforms, plus a few bits of meta data. Tab 3 was my attempt to go through some of the more "popular" plugins, analyizing their suitability for packaging via pluginstall. Where it fell short I documented. Green means good to go as-is, red means some issues, yellow means unsure (might be ok.) I'd love some more feedback on this. the doc is globally shared so everyone can modify it. I think we could use tab 3 to coordinate our work and provide visibility. thoughts? -Mike On Tue, Oct 9, 2012 at 7:44 PM, Andrew Lunny <alu...@gmail.com> wrote: > I've missed most of this discussion, but I wanted to make a few quick > points: > > * `pluginstall` (the tool I developed, that is used by PhoneGap Build) is a > tool for installing plugins. Per the Unix philosophy, it doesn't and won't > do anything other than that. > > * There may well be a need and a demand for a tool that grabs plugins from > git repositories, uninstalls plugins, generates starter plugins, etc. But > that's not pluginstall, and I think that tool should probably be named > something else. It looks like Mike has made a start on that with his > cordova-pluginrepo repository, which is awesome. > > * The problems that need to be solved by pluginstall are of the form "I > can't install plugin x with pluginstall", or "I can't write a plugin that > does x that can be installed by pluginstall." The only way to find those > problems is to try writing those plugins. The PGB team is moving forward on > a few, and we've worked with some other companies who have helped us see > where pluginstall was lacking (adding multiple children to an Android > intent-filter, installing a dylib into an iOS project). > > * node-xcode is a separate project, and will be useful for any plugin tools > written with node. It would probably be better for everyone's sanity if > there was a single version of that parser. I've been pretty slack about > merging changes, so I'll get up to speed on that. > > * If other tools want to interoperate with pluginstall, they should follow > the plugin spec here: > https://github.com/alunny/cordova-plugin-spec > That's a working document and is open to changes. Again, my preference is > for changes of the form "I can't write a plugin that does X in this format" > rather than "this element has a slightly misleading name; how about this > name?". The GitHub issues for that repo is the best place to discuss > changes to that spec. > > Cheers, > Andrew > > On 6 October 2012 09:08, Mike Reinstein <reinstein.m...@gmail.com> wrote: > > > Andrew's is the one used by pg build. Anis has changes from all of us and > > has the most the up to date code: > > > > https://github.com/imhotep/pluginstall > > > > -Mike > > > > > > > > On Sat, Oct 6, 2012 at 8:08 AM, Patrick Mueller <pmue...@gmail.com> > wrote: > > > > > On Sat, Oct 6, 2012 at 5:22 AM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > Think its time we nominated a canonical repo for this. Fil's? > > > > > > > > > > URL please? Are we talking about forks of pluginstall? > > > > > > -- > > > Patrick Mueller > > > http://muellerware.org > > > > > >
