Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6CA7A11C90 for ; Tue, 3 Jun 2014 23:46:28 +0000 (UTC) Received: (qmail 27711 invoked by uid 500); 3 Jun 2014 23:46:28 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 27680 invoked by uid 500); 3 Jun 2014 23:46:28 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 27670 invoked by uid 99); 3 Jun 2014 23:46:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 23:46:28 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [64.202.189.19] (HELO m1plded02-02.prod.mesa1.secureserver.net) (64.202.189.19) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 23:46:24 +0000 Received: from listing-agent.com ([68.178.129.131]) by m1plded02-02.prod.mesa1.secureserver.net with : DED : id 9zly1o0342qERHw01zly0R; Tue, 03 Jun 2014 16:45:59 -0700 x-originating-ip: 68.178.129.131 Received: from [192.168.0.2] (cpe-72-182-62-152.austin.res.rr.com [72.182.62.152]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by listing-agent.com (Postfix) with ESMTPSA id 590ED10F0BCE for ; Tue, 3 Jun 2014 16:45:09 -0700 (MST) Message-ID: <538E5E17.6020502@tmbsw.com> Date: Tue, 03 Jun 2014 18:45:27 -0500 From: "Terence M. Bandoian" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dev@cordova.apache.org Subject: Re: adding platforms to npm for dependency sanity References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Forgetting about plugins for a second, what if: - I complete a project for iOS - six months later the client decides to port to Android and: - I want the latest fixes for Android - I want to keep the iOS version frozen for the time being I would expect releases for each platform to be on different schedules. -Terence On 6/3/2014 6:17 PM, Michal Mocny wrote: > Most plugins will work across a wide range of platform versions, so often > it would work to have disparate platform versions even with plugins. > However, I do concede that in general this isn't a complexity we focus on. > > Interested in your thoughts about the other points. > > -Michal > > > On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams > wrote: > >> You can’t have version x of a plugin for iOS and version y of that same >> plugin for Android, so multiple platform versions seems like a complexity >> for complexity’s sake. >> >> It’s true that different apps need to support different platform versions, >> but I would suspect that the greatest majority of those would want the same >> version of iOS and Android in app x. >> >> >> >> On 4 June 2014 at 9:04:42, Brian LeRoux (b@brian.io) wrote: >> >> That is the thing: you do not EVER want to have disparate versions of >> platforms. Plugins negate this potential fantasy. >> >> You want version locked deps. You want to use package.json to do that b/c >> that is what the runtime we use has standardized itself on. >> >> >> On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian >> wrote: >> >>> A typical use case might be: >>> >>> -project1 >>> -project1-ios >>> -project1-android >>> -project1-windows >>> ... >>> -projectN >>> -projectN-ios >>> -projectN-android >>> -projectN-windows >>> >>> with a different platform version for each sub-project. >>> >>> Would CLI be installed globally? Locally for each sub-project? Would a >>> project-platform have to be re-built if a plugin were added? >>> >>> -Terence >>> >>> >>> On 6/3/2014 1:47 PM, Michal Mocny wrote: >>> >>>> Okay, so I think that implies: >>>> >>>> (a) CLI versions tied to very specific platform versions ==> to switch >>>> platform versions you must switching CLI versions ==> switching one >>>> platform version switches all platform versions. >>>> - Andrew pointed out this is currently the case, and is a problem that >>>> leads to users not updating CLI as often as they otherwise would >>>> - I think this basically implies platforms cannot be independently >>>> versioned (sure the semver numbers may differ, but for all practical >>>> purposes, you would use platforms from the same release date, based on >> CLI >>>> version). >>>> >>>> (b) Require apps to depend on specific CLI version, assuming you mean >> with >>>> a local package.json: >>>> - Now all cordova projects must be node projects, which they currently >> are >>>> not. >>>> - Currently the cordova-cli creates apps, so we have a globally >> installed >>>> bootstrapping cordova-cli, and a locally installed specific version >>>> cordova-cli, a-la grunt/gulp. (this idea was thrown around before). >>>> - Quite a dramatic change for cordova workflow, surely larger than the >>>> current proposal. >>>> - Or we drop cordova-cli entirely and just publish grunt/gulp plugins to >>>> "add cordova" to your existing web app. Thats an even more radical >>>> departure and significant work. >>>> >>>> -Michal >>>> >>>> >>>> On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux wrote: >>>> >>>> No, at least not how I'd see it done. >>>>> 1.) Updating is important. Staying current: encouraged. >>>>> 2.) I'd make my App depend on a specific CLI version. I'd call into >> that >>>>> using npm scripts. >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny >>>>> wrote: >>>>> >>>>> Thinking it through, if cordova platforms are deps of the CLI, to >>>>> install a >>>>> >>>>>> specific version you wouldn't just do: >>>>>> >>>>>>> npm install -g cordova-ios@3.4.1 >>>>>>> >>>>>> you would actually need to: >>>>>> >>>>>>> cd $(npm config get prefix)/lib/node_modules/cordova >>>>>>> npm install --save cordova-ios@3.4.1 >>>>>>> >>>>>> ..and then remember to do that again whenever you `npm update -g` >>>>>> ..and its harder to have multiple platform versions for different >>>>>> >>>>> projects >>>>> >>>>>> (questionable if this is useful for devs outside of cordova >>>>>> contributors, >>>>>> but may be useful at last test upgrades when we ship new platform >>>>>> versions). >>>>>> >>>>>> -Michal >>>>>> >>>>>> >>>>>> On Tue, Jun 3, 2014 at 1:28 PM, Brian LeRoux wrote: >>>>>> >>>>>> NIH: not invented here >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve >>>>>> wrote: >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux wrote: >>>>>>>> Actually that was >0 LOC which is a fine argument if you ask me. >>>>>>>> And >>>>>> we >>>>>> >>>>>>> both know there is much more to it than just that. lazy_load…for >>>>>>>> example. >>>>>>>> If you're concerned about code, there is a tonne of much >>>>>>>> >>>>>>> lower-hanging >>>>>> fruit. >>>>>>>> >>>>>>>> Bundling platforms is bundling a dep that we require to operate. We >>>>>>>> do >>>>>>> not >>>>>>>>> require plugins to operate. You cannot build a project without >>>>>>>>> >>>>>>>> having a >>>>>>> platform and, indeed, you probably want more than one. >>>>>>>>> I don't require blackberry to create an iOS project. But I do >>>>>>>> require >>>>>>>> >>>>>>> some >>>>>>> >>>>>>>> plugins. We use "npm cache add" to download plugins, I don't see how >>>>>>>> platforms would not work just as easily. >>>>>>>> >>>>>>>> >>>>>>>> Agree that we need discreet versioning: hence why I'm advocating we >>>>>>>> use >>>>>>> well understood, maintained, and effectively standard system for >>>>>>>> doing >>>>>>> this. We do not need NIH dependencies that is what package.json is >>>>>>>> for! >>>>>>> I don't know what NIH dependencies are. Googling suggests you're >>>>>>> talking >>>>>>> about drugs... >>>>>>>> We *are* using npm for downloading, we're just not making the user >>>>>>>> >>>>>>> type >>>>>> it >>>>>>>> directly. >>>>>>>> >>>>>>>> Mark's approach also avoids the "what-if" cases where what's in your >>>>>>>> node_modules might not match what's in your platforms/ >>>>>>>> >>>>>>>> Does what Mark has implemented not address a use-case of yours? Or >>>>>>>> >>>>>>> are >>>>>> we >>>>>> >>>>>>> going back & forth over personal preference? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 3, 2014 at 9:07 AM, Andrew Grieve < >>>>>>>>> >>>>>>>> agrieve@chromium.org> >>>>>> wrote: >>>>>>>>> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux >>>>>>>>> wrote: >>>>>> Andrew, you misunderstand. I am talking about bundling >>>>>>>>>> platforms >>>>>> directly >>>>>>>>>> as dependencies of the CLI. >>>>>>>>>>> A trivial example: >>>>>>>>>>> >>>>>>>>>>> CLI >>>>>>>>>>> '-ios >>>>>>>>>>> >>>>>>>>>>> Wherein, CLI declares the precise version of the platform it >>>>>>>>>>> >>>>>>>>>> uses. >>>>>>> We >>>>>>> >>>>>>>> could >>>>>>>>>>> wildcard. I don't know that we want or need to do that. >>>>>>>>>>> >>>>>>>>>>> It would have identical semantics to today except the download >>>>>>>>>>> >>>>>>>>>> penalty >>>>>>>>> happens up front. (We can remove lazy_load logic. We don't have >>>>>>>>>> to >>>>>>> maintain >>>>>>>>>>> our own dependency manifests and caches. LESS code: good >>>>>>>>>>> >>>>>>>>>> thing.) >>>>>> Let me paste the code for doing our own caching for you: >>>>>>>>>> cordova_npm: function lazy_load_npm(platform) { >>>>>>>>>> if (!(platform in platforms)) { >>>>>>>>>> return Q.reject(new Error('Cordova library "' + >>>>>>>>>> >>>>>>>>> platform >>>>>>> + >>>>>>> >>>>>>>> '" >>>>>>>> >>>>>>>>> not recognized.')); >>>>>>>>>> } >>>>>>>>>> var pkg = 'cordova-' + platform + '@' + >>>>>>>>>> platforms[platform].version; >>>>>>>>>> return Q.nfcall( npm.load, {cache: >>>>>>>>>> >>>>>>>>> path.join(util.libDirectory, >>>>>>>> 'npm_cache') }) >>>>>>>>>> .then(function() { >>>>>>>>>> return Q.ninvoke(npm.commands, 'cache', ['add', >>>>>>>>>> >>>>>>>>> pkg]); >>>>>> }).then(function(info) { >>>>>>>>>> var pkgDir = path.resolve(npm.cache, info.name, >>>>>>>>>> >>>>>>>>> info.version, >>>>>>>>> >>>>>>>>>> 'package'); >>>>>>>>>> return pkgDir; >>>>>>>>>> }); >>>>>>>>>> }, >>>>>>>>>> >>>>>>>>>> There's really no "amount of code" argument here. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Adding platforms at a specific version would mean having a >>>>>>>>>> specific >>>>>>> version >>>>>>>>>>> of the CLI. Yes: this is way better! Explicit dependencies is >>>>>>>>>>> >>>>>>>>>> the >>>>>> best >>>>>>>>> way >>>>>>>>>>> to work w/ the small modules thing. >>>>>>>>>>> >>>>>>>>>>> Bundling platforms with CLI would be like bundling all of the >>>>>>>>> plugins >>>>>>> with >>>>>>>>>> CLI, or like bundling every npm module with npm. >>>>>>>>>> >>>>>>>>>> Devs need to be able to try out platforms at different versions. >>>>>>>>>> >>>>>>>>> We >>>>>> should >>>>>>>>>> not do anything that keeps users clinging to old versions of CLI >>>>>>>>>> >>>>>>>>> (e.g. >>>>>>>> they >>>>>>>>>> do this now because they don't want to update to new platforms) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jun 2, 2014 at 7:34 PM, Michal Mocny < >>>>>>>>>>> >>>>>>>>>> mmocny@chromium.org> >>>>>>> wrote: >>>>>>>>>>> On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve < >>>>>>>>>>> agrieve@chromium.org >>>>>>>>> wrote: >>>>>>>>>>>> Here's both flows as I understand them: >>>>>>>>>>>>> Direct NPM flow: >>>>>>>>>>>>> # Downloads platform source into node_modules >>>>>>>>>>>>> npm install cordova-ios@3.4.0 --save >>>>>>>>>>>>> # Runs the create script and installs plugins to create >>>>>>>>>>>>> >>>>>>>>>>>> platforms/ios >>>>>>>>>> cordova platform add ios --path=node_modules/cordova-ios >>>>>>>>>>>>> To be fair, I think with Brian's suggestion, platform add FOO >>>>>>>>>>> would >>>>>>>> by >>>>>>>>>> default look in node_modules so you wouldn't be explicit >>>>>>>>>>> about >>>>>> it, >>>>>>>> and >>>>>>>>>> also >>>>>>>>>>>> the default cordova project package.json would depend on all >>>>>>>>>>>> >>>>>>>>>>> the >>>>>>> latest >>>>>>>>>> versions of each platform, so the flows would actually be: >>>>>>>>>>>>> cordova create Foo && cd Foo >>>>>>>>>>>>> npm install >>>>>>>>>>>>> npm install cordova-ios@3.4 --save >>>>>>>>>>>>> cordova platform add android >>>>>>>>>>>>> cordova platform add ios >>>>>>>>>>>>> # crazy idea? use npm post-install hooks to auto-run >>>>>>>>>>>>> >>>>>>>>>>>> create/upgrade >>>>>>>>> so >>>>>>>>>>> you usually don't need above two lines? >>>>>>>>>>>> Compared to: >>>>>>>>>>>> >>>>>>>>>>>>> cordova create Foo && cd Foo >>>>>>>>>>>>> cordova platform add android >>>>>>>>>>>>> cordova platform add ios@3.4 >>>>>>>>>>>>> >>>>>>>>>>>> I think #2 is enough better that its not worth changing. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cordova-to-npm flow (as Mark's implemented): >>>>>>>>>>>>> # Runs "npm cache add cordova-ios", then runs create script >>>>>>>>>>>>> >>>>>>>>>>>> from >>>>>>>> ~/cache/cordova-ios/bin/create >>>>>>>>>>>>> cordova platform add ios@3.4.0 >>>>>>>>>>>>> >>>>>>>>>>>>> - In both flows: we use npm to do all of the heavy lifting >>>>>>>>>>>>> - In both flows: the npm module is cached in your home >>>>>>>>>>>>> >>>>>>>>>>>> directory >>>>>>>> - In both flows?: we store the plugins & platforms >>>>>>>>>>>> explicitly >>>>>> within >>>>>>>>>> config.xml (Gorkem's added this) >>>>>>>>>>>>> - In flow #1, we have a package.json & a node_modules, in >>>>>>>>>>>>> >>>>>>>>>>>> #2 >>>>>> we >>>>>> >>>>>>> don't. >>>>>>>>>>> Why put the onus on the user to fetch the platform source >>>>>>>>>>>> when >>>>>>> it's >>>>>>>>> as >>>>>>>>>>> easy >>>>>>>>>>>>> as running "npm cache add" under-the-hood? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In regards to the idea of using require() on platform >>>>>>>>>>>>> >>>>>>>>>>>> scripts >>>>>> instead >>>>>>>>>> of >>>>>>>>>>>> subshelling: I think this is tangental to the debate of how >>>>>>>>>>>> to >>>>>>> fetch >>>>>>>>>> the >>>>>>>>>>>> platform. >>>>>>>>>>>>> In regards to using "npm install" directly when using the >>>>>>>>>>>>> >>>>>>>>>>>> plugman >>>>>>>> workflow: >>>>>>>>>>>>> Sounds good to me. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Jun 2, 2014 at 6:05 PM, Brian LeRoux >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>> Eventually, yes. (Sort of how Grunt works now.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian < >>>>>>>>>>>>>> >>>>>>>>>>>>> terence@tmbsw.com >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Can multiple versions of a platform be installed >>>>>>>>>>>>>> side-by-side? >>>>>>>>> -Terence >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/2/2014 3:04 PM, Michal Mocny wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >From original email: "Ideal future CLI uses platforms >>>>>>>>>>>>>>> just >>>>>>>> like >>>>>>>>>> other >>>>>>>>>>>>> deps. >>>>>>>>>>>>>>>> We lose lazy loading but network and disk is cheap so >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> it >>>>>> wasn't >>>>>>>>>> really >>>>>>>>>>>>> important anyhow." >>>>>>>>>>>>>>>> Made me think Brian is proposing adding platforms to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cli >>>>>> package.json >>>>>>>>>>>>> dependencies, and you would have a single global >>>>>>>>>>>>>>> install >>>>>> cordova-platforms. >>>>>>>>>>>>>>>> Then you can override the version with an explicit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> install >>>>>>>> as >>>>>>>>>> he >>>>>>>>>> >>>>>>>>>>> mentions >>>>>>>>>>>>>>>> "npm i cordova-ios@3.5.0". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Personally, I think that workflow could work, and has >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a >>>>>> few >>>>>>>> benefits, >>>>>>>>>>>>> but >>>>>>>>>>>>>>> I'm not sure that option compares well to the >>>>>>>>>>>>>>> alternative >>>>>>> of >>>>>>> >>>>>>>> just >>>>>>>>>>> lazy >>>>>>>>>>>>> loading using npm cache add as Mark has already >>>>>>>>>>>>>>> implemented >>>>>>>> an >>>>>>>> >>>>>>>>> experiment >>>>>>>>>>>>>>> (anyone interested in this topic should take a look at >>>>>>>>>>>>>>> that >>>>>>>> patch). >>>>>>>>>>>> The steps Brian & Ian outline about how to package >>>>>>>>>>>>>>> platforms >>>>>>>> for >>>>>>>>>> release >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> npm are possibly an improvement over the old-style >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> platform-centric >>>>>>>>>>>> workflow. Instead of downloading a tarball and >>>>>>>>>>>>>>> running >>>>>> a >>>>>> >>>>>>> create >>>>>>>>>> script, >>>>>>>>>>>>>> you npm install and run a create() function, and that >>>>>>>>>>>>>>> can >>>>>>> more >>>>>>>>> easily >>>>>>>>>>>>> be >>>>>>>>>>>>> >>>>>>>>>>>>>> bundled into other build scripts/boilerplate. For CLI >>>>>>>>>>>>>>> workflow, >>>>>>>>>> not >>>>>>>>>>>> sure >>>>>>>>>>>>>>> that there is any real difference (as Jesse says). >>>>>>>>>>>>>>> One >>>>>> note, >>>>>>>>> though: >>>>>>>>>>>>> cordova-* platforms are templates for projects, so >>>>>>>>>>>>>>> the >>>>>> package.json >>>>>>>>>>>>> of >>>>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> npm package itself shouldn't end up inside projects >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> that >>>>>> are >>>>>>>> created >>>>>>>>>>>> with >>>>>>>>>>>>>>> it. I think. >>>>>>>>>>>>>>>> -Michal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:42 PM, Ian Clelland < >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> iclelland@chromium.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> There seems to be some confusion -- I think people >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> are >>>>>> talking >>>>>>>>>> about >>>>>>>>>>>>> different things here, but perhaps it's just me ;) >>>>>>>>>>>>>>>>> I thought that Brian's original suggestion was about >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> being >>>>>>>> able >>>>>>>>>> to >>>>>>>>>>>> host >>>>>>>>>>>>>> Cordova platforms directly on NPM. That's why each >>>>>>>>>>>>>>>> one >>>>>> would >>>>>>>>> require >>>>>>>>>>>>> a >>>>>>>>>>>>> >>>>>>>>>>>>>> package.json. (which would probably end up in >>>>>>>>>>>>>>>>> /platforms/ in a project, but >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that's >>>>>> not >>>>>>>> the >>>>>>>>>> point >>>>>>>>>>>>> of >>>>>>>>>>>>>>> it). >>>>>>>>>>>>>>>>> As an NPM project, we then would have the opportunity >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (though >>>>>>>>> not >>>>>>>>>>> the >>>>>>>>>>>>> obligation) to make all of the supporting scripts for >>>>>>>>>>>>>>>> each >>>>>>>> platform >>>>>>>>>>>> (create, build, run, etc) part of the node module, >>>>>>>>>>>>>>>> for >>>>>> a >>>>>> >>>>>>> uniform >>>>>>>>>>> interface >>>>>>>>>>>>>>>>> that doesn't require going through the command line. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It's not about making platforms into CLI dependencies >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (any >>>>>>>> more >>>>>>>>>> than >>>>>>>>>>>>> plugins are CLI dependencies right now), or about >>>>>>>>>>>>>>>> making >>>>>>> a >>>>>>> >>>>>>>> cordova-based >>>>>>>>>>>>>>> project into a node package. >>>>>>>>>>>>>>>>> If that's right, then I support that -- I'd like the >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> platforms >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>>> be >>>>>>>>>>>>> installable through npm, and to be versioned >>>>>>>>>>>>>>>> separately, >>>>>>> installable >>>>>>>>>>>>> separately, and scriptable without having to spawn >>>>>>>>>>>>>>>> subshells. >>>>>>>>> And if I have it completely wrong, then let me know >>>>>>>>>>>>>>>> -- >>>>>> I'll >>>>>>>> just >>>>>>>>>>> go >>>>>>>>>>> >>>>>>>>>>>> back >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> fixing File bugs ;) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:29 PM, Andrew Grieve < >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> agrieve@chromium.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Not sure what your question is. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux < >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> b@brian.io> >>>>>>>> wrote: >>>>>>>>>>>> *ahem >>>>>>>>>>>>>>>>>>> On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux < >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> b@brian.io >>>>>>>>> wrote: >>>>>>>>>>>>> npm i cordova-ios@3.5.0 >>>>>>>>>>>>>>>>>>>> Right? >>>>>>>>>>>>>>>>>>>> On May 27, 2014 11:06 PM, "Andrew Grieve" < >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> agrieve@chromium.org >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Lazy loading is what will give us the ability to >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> support >>>>>>>> multiple >>>>>>>>>>>> versions >>>>>>>>>>>>>>>>>>>> of platforms. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If we don't support users choosing the version of >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> the >>>>>>> platform >>>>>>>>>>>> they >>>>>>>>>>>>>> want, >>>>>>>>>>>>>>>>>>>> then they will resist updating their version of >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> CLI >>>>>> (like >>>>>>>>> they >>>>>>>>>>> do >>>>>>>>>>>>> right >>>>>>>>>>>>>>>>>>> now). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm very keen to allow users to chose their >>>>>>>>>>>>>>>>>>>> platform >>>>>>> versions, >>>>>>>>>>>> just >>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>>>> are able to choose their plugin versions. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, May 27, 2014 at 5:57 PM, Mark Koudritsky >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> < >>>>>> kamrik@google.com >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Steve published (some of?) the platforms on npm >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> as >>>>>> part >>>>>>>>> of >>>>>>>>> >>>>>>>>>> the >>>>>>>>>>>> latest >>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>> https://www.npmjs.org/package/cordova-android >>>>>>>>>>>>>>>>>>>>>> https://www.npmjs.org/package/cordova-ios >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> CLI already require()s npm for downloading >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> plugins >>>>>> from >>>>>>>>> the >>>>>>>>>>> registry. >>>>>>>>>>>>>>>>>>>> Extending this to platforms is on my todo list for >>>>>>>>>>>>>>>>>> this\next >>>>>>>>>> week. >>>>>>>>>>>>> The "lazy" part of the loading was about >>>>>>>>>>>>>>>>>>>>> caching, >>>>>> so >>>>>> >>>>>>> we >>>>>>>>> don't >>>>>>>>>>>> lose >>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>> npm does its own caching. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, May 27, 2014 at 5:42 PM, Parashuram >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Narasimhan >>>>>>>> (MS >>>>>>>>>> OPEN >>>>>>>>>>>>> TECH) >>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>> panarasi@microsoft.com> wrote: >>>>>>>>>>>>>>>>>>>>> +1. This will also be a step towards releasing >>>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>> independently. >>>>>>>>>>>>>>>>>>>>>> Will the CLI have a semver like dependency on >>>>>>>>>>>>>>>>>>>>> >>