I think we have a hangout scheduled for that conversation (among others) right? Its good that Braden is setting up topics of conversation :)
-Michal On Wed, Feb 27, 2013 at 4:37 PM, Filip Maj <[email protected]> wrote: > I think this is a good conversation to have. > > Note that, if we do split up how plugins are treated and when we copy > files around (I.e. Move the www assets on every prepare, but the native > files only on platform/plugin adds), then the plugman tool will either > need finer-grained support for these types of actions or we need to > assimilate/couple the plugman code closer to cordova-cli. > > On 2/27/13 1:32 PM, "Braden Shepherdson" <[email protected]> wrote: > > >I'm on the fence about native plugin code. I think iOS has some > >complications there. > > > >Over the course of my work on the installation prototype, I've actually > >moved to copying plugin www files on every prepare, that works great. > > > >For native code, I wonder if that's best done on add/remove. I was mostly > >thinking about www files for the original proposal. > > > >Braden > > > > > >On Wed, Feb 27, 2013 at 4:24 PM, Filip Maj <[email protected]> wrote: > > > >> 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 > >> >> > >> > >> > >
