Couple notes before I add some comments: - in general plugin add and rm is COMPLETELY delegated to the plugman tool. See [1]. Most of the code linked is error checking, otherwise it shells out to plugman.. With one exception.. - what happens in [2]. Which is the point Braden brought up about polluting the user's www. Totally agree this should change. At the time of writing that I dropped a TODO [3] that this was a likely bad assumption. - the "what plugins are installed" code is already a `ls plugins/` run [4].
Now going back to your proposal: 1. Never pollute user's www. I completely agree with this. Time to refactor that out. 2. Use existence of directories under the ./plugins dir to identify which plugins are installed. Yep. Already does that as shown in [4]. If I understand correctly, you are proposing we run a plugin installation (I.e. Copy over appropriate files and edit config files) every time cordova prepare is run. This would mean that every time we run prepare, we have to recreate a native cordova project (otherwise we'd be installing plugin files into the native project on every command). I'm not sure I agree with this.. I have to think more about it.. I think this conversation boils down to: should we be recreating cordova projects on every command, or keep the native projects "persistent" across commands (which is currently how it operates). [1] https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L72 [2] https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L116 [3] https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L117-L118 [4] https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L51-L52 On 2/25/13 8:24 AM, "Michal Mocny" <[email protected]> wrote: >Just to clarify this in my head: > >* Since we have a prepare step now, you propose moving some of the logic >that used to run on plugin add out into the prepare step. That sounds >good. >* You want to fix how we track which plugins are installed by going to >source instead of some config file. That sounds good. >* You want to fix a bunch of stuff with the prepare step (including the >current add logic). I can't really comment on specifics here, but I guess >this is not as radical of a change as I thought on first pass. > >I briefly asked you offline but wanted to bring it into the ML: How does >this proposal affect our current plan for plugin upgrading? (Your answer, >paraphrasing, was that prepare step should ideally be stateless and start >from any clean state. Thus, upgrade is simply an rm & add & prepare) > >-Michal > > >On Mon, Feb 25, 2013 at 10:32 AM, Braden Shepherdson ><[email protected]>wrote: > >> I'm running into several problems with the current implementation of >> cordova-cli: >> >> * There's no single source of truth for what plugins are installed. It >>uses >> the presence of a plugin's name in the www/config.xml currently. This >> doesn't work for JS-only plugins, and there are some, especially on >>other >> platforms. >> * It's polluting (maybe clobbering!) the user's www/ during plugin add. >> * It expects plugins to have a www/ directory it copies whole into the >> top-level www/, rather than honouring <asset> tags as per docs. >> >> My proposal is to rewire cordova-cli according to two principles: >> >> 1. We never pollute the user's www/ with anything. Full stop. >>Everything we >> do automagically goes into the platform directories at cordova prepare >> time. >> 2. We use the existence of absence of directories in plugins/ as the >>source >> of truth for what is or isn't installed. >> >> Under this model, plugin add/rm become fancy aliases for cp -R and rm >>-rf. >> No magic or copying of JS or native files or config editing or anything >> else happens on plugin add: We just copy the directory into plugins/. >> >> Then on cordova prepare, we copy native files into the platforms, edit >> platform-specific config files to include <plugin> tags and permissions >>and >> list the native files. >> >> iOS makes this hard, since it has a project file that lists all native >> files in the project. We can get around this by putting all plugin files >> into a subdirectory like src/plugins. Then on cordova prepare we can get >> every file in that directory, remove them from the project file, delete >> them, then copy every plugin's native files and add them to the project >> file. Then the project file always matches the current load of plugins. >> >> I'm volunteering to do the work required for this. I just want to run >>the >> idea past people before I start fundamentally changing how the tool >>works. >> I think this will make many parts of the code simpler to read and >>document, >> and make the behavior of the tool much clearer and less magical to >>users. >> >> Braden >>
