Yea, I believe the plan is the lazy-load the platforms to a global configuration directory. The lazy-load would only happen on the first request for a given platform. Any future requests would use the cached platform.
For example: ~/.cordova/platform/cordova-android-2.7.0/ Andrew, I think your advantages are accurate. I would also add: 4. Removes need to `sudo chown username /path/to/global/npm/cordova/` I've got a lot on my plate right now, but I am hoping to get started on this lazy-loading asap. Michael On Tue, Apr 30, 2013 at 8:56 AM, Filip Maj <f...@adobe.com> wrote: > Yeah, Michael Brooks was working towards lazy-loading the libraries as you > need them. > > On 4/30/13 5:08 AM, "Andrew Grieve" <agri...@chromium.org> wrote: > > >Actually... Now I think I'm remembering that there was talk about not > >including these at all... Was that right? We were going to package them up > >as separate npm targets, or have CLI be able to download them on demand as > >zip files? > > > > > >On Mon, Apr 29, 2013 at 10:28 PM, Andrew Grieve > ><agri...@chromium.org>wrote: > > > >> Right now we have a copy / paste of the entire cordova-ios, > >> cordova-android, cordova-blackberry directories within cordova-cli/lib. > >>I'm > >> wondering if we should change these to be submodules. > >> > >> Git submodules often don't work well because they don't automatically > >> track branches. In this case though, I think they do exactly what we'd > >>want > >> them to - to point to a specific commit hash. > >> > >> Advantages: > >> 1. cordova-cli currently takes a while to clone since its index is so > >>big. > >> Using submodules would mean the index would stop growing so much (not > >>sure > >> if we can purge the currently copies from index). > >> 2. It would be clear that the copies within CLI do not have any > >> modifications > >> 3. Would be easier to update them for each release > >> > >
