On Wed, Jun 4, 2014 at 5:53 PM, Andrew Grieve <agri...@chromium.org> wrote: > Things I think are good ideas: > - platforms providing an index.js that node can consume. If project scripts > are not in node, then they can just subshell (or port to node). > - making it easier to consume CLI from grunt / whatever > - enabling users to do their own fetching rather than CLI doing the > fetching (e.g. via node_modules or via .zip on dist/ or via github) > > Things I think are bad ideas: > - start enforcing that Cordova projects are node projects > - requiring a tools release every time any of the platforms want to do a > release > - changing the Cordova workflow in a major way so soon after 3.0
It's been almost a year since Cordova 3.0 has been released. Just because we haven't shipped doesn't mean that time has not passed. > > re: Having different versions of platforms and plugins is a recipe for > disaster > > Platforms are already versioned separately. They will be released > separately in the near future (or at least that's what we're working > towards). If you don't agree with this, then we should step back and debate > this first. > AFAIK, no platform has released a version past 3.5 so far. I honestly don't know if versioning the platforms separately is going to help our users at all, because we haven't released anything since 3.5. I actually think it's going to make people's lives worse since we'll have disparate platforms. I do think we should debate this, since this point has bogged down our release process almost as much as "The Apache Way" has. > Plugins are x-platform, but the native code for each platform has almost > zero overlap. It therefore makes sense to want to specify their > dependencies separately. E.g.: > > <engines> > <engine name="cordova-android" version=">=4.0.0" /> > <engine name="cordova-ios" version=">=3.2.0" /> > </engines> > > For example, we'll need to bump many of the requirements to support > cordova-android@4.0, but they will still work fine with cordova-* at older > versions. If a project is ios-only, we don't want to force them to update > to a new version of iOS just because the plugin requires a newer version of > cordova-android. > This is going to create dependency hell. People already have weird ideas of what versions of Cordova they should use because of their gut feeling, or their experience with random plugin X. We want people to upgrade to the latest so that they're relatively secure, and this will do the opposite of making it so that people rely on possibly vulnerable versions of Cordova because some third-party plugin guy wants to bind the version to something broken. > Not sure what you mean by different versions of plugins. One of the design > goals of plugins was that you can stick to an old version if you'd like. > > re my "all talk" comment: > > Sorry for being snarky here. We often do have discussions that end up with > agreement but no on willing to do the work. I am genuinely interested if > you're discussing this because it's a neat idea, or doing so because you > intend to implement some of these ideas. > If nobody is willing to do the work, it probably wasn't a good idea, or not as important as the list made it sound. > > > On Wed, Jun 4, 2014 at 7:07 PM, tommy-carlos williams <to...@devgeeks.org> > wrote: > >> WRT plugins not being tied to a version of the platforms… We at SpiderOak >> have a project that is still stuck at 3.0.0 for precisely that reason. >> > Could you elaborate? I'm not sure what you're getting at with this. > e.g. Are you not updating CLI because of this? > e.g. Are you holding back iOS because plugins don't work with newer Android? > > >> >> As for the CLI not being tied to a platform version, that’s also not true. >> Don’t know if you have tried it, but using a current version of the CLI >> with a project created and “platformed” with a previous version is also a >> recipe for disaster. >> > Other than "platform update" not being very good, I don't think we've had > any bugs for newer CLIs not working with older platforms. What doesn't work? > > > >> >> >> >> On 5 June 2014 at 8:48:48, Brian LeRoux (b...@brian.io) wrote: >> >> Plugins have to target specific versions. [1] Core plugins, our org.apache >> plugins, are cross platform. [2] >> >> This is not conceptual but the current reality and a correct software >> practice. >> >> [1] >> >> https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33 >> [2] https://github.com/apache/cordova-plugin-inappbrowser/tree/master/src >> >> >> On Wed, Jun 4, 2014 at 5:32 PM, Terence M. Bandoian <tere...@tmbsw.com> >> wrote: >> >> > Why is having different versions of platforms a recipe for disaster? >> > >> > -Terence >> > >> > >> > On 6/4/2014 4:29 PM, Brian LeRoux wrote: >> > >> >> As discussed: having different versions of platforms and plugins is a >> >> recipe for disaster. The design choice of version locking is deliberate >> to >> >> avoid that. I'm going to ignore the ramble about grunt, etc. I'm not >> >> advocating for that nor am I interested in javascript build library >> >> fashion. Those things are not problems we seek to solve here. >> >> >> >> Also: this is not talk. Its building consensus to *continue* the work >> >> being >> >> done into a direction that everyone feels good about. The alternative is >> >> patchbombing and a massive delete of google employee commits which is >> >> probably not productive. >> >> >> >> >> >> >> >> On Wed, Jun 4, 2014 at 2:16 PM, Andrew Grieve <agri...@chromium.org> >> >> wrote: >> >> >> >> Brian's and Carlos' examples have a very important difference: >> >>> >> >>> Brian's: platforms are dependencies of CLI >> >>> Carlos': platforms are siblings of CLI in top-level package.json >> >>> >> >>> With Carlos', the user can easily control versions of the platforms, >> >>> which >> >>> is great. You could just as easily put plugins in there now that npm >> >>> supports multiple registries as well. >> >>> >> >>> I don't think you'd need CLI at all with this setup. Just use plugman & >> >>> grunt & recreate your project on every build. I think it's a nice >> >>> workflow, >> >>> but I'm afraid that dramatically changing out documented workflow again >> >>> so >> >>> soon would be an unwelcome change. I also think it'd be a good amount >> of >> >>> work to make our tools smart enough to work alongside npm in a way that >> >>> isn't confusing (e.g. if we're recreating every time, we'll need to >> speed >> >>> it up a lot. If not, then you need to tell it when dependencies >> change). >> >>> >> >>> My main goal for now is to get to where we can release platforms >> >>> independently, but I'm curious if this is all talk or is anyone >> intending >> >>> to do some real exploration in this area? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Wed, Jun 4, 2014 at 4:55 PM, Brian LeRoux <b...@brian.io> wrote: >> >>> >> >>> Here is an example using our current situation. Cordova is versioned >> [1] >> >>>> and the CLI calls are abstracted as npm scripts [2]. If we change to >> the >> >>>> proposed 'versioning platforms using npm' we don't have to download >> >>>> platforms, cache them or perform any custom dependency logic. >> >>>> >> >>>> We will then be well on the path to making the CLI *really* dumb and >> it >> >>>> will only pass calls down to the lib installed in node_modules. >> >>>> >> >>>> HTH >> >>>> >> >>>> [1] >> >>>> >> >>>> >> >>>> https://github.com/brianleroux/cordova-example- >> >>> using-npm/blob/master/package.json#L13 >> >>> >> >>>> [2] >> >>>> >> >>>> >> >>>> https://github.com/brianleroux/cordova-example- >> >>> using-npm/blob/master/package.json#L8 >> >>> >> >>>> >> >>>> On Wed, Jun 4, 2014 at 1:38 PM, Carlos Santana <csantan...@gmail.com> >> >>>> wrote: >> >>>> >> >>>> Michal >> >>>>> The grunt plugin and yeoman generator I implemented a long ago. So >> >>>>> >> >>>> it's >> >>> >> >>>> implemented on top of what cordova provides. >> >>>>> >> >>>>> I'm confuse, this is the point I was trying to get that there is >> "user >> >>>>> space" and "cordova platform space", Doing a plugin for yeoman, gulp >> , >> >>>>> grunt, or the next thing is user space. >> >>>>> >> >>>>> cordova as a platform should be using flexbile and clear on what is >> >>>>> >> >>>> doing, >> >>>> >> >>>>> so "user space" can customize on top of it. >> >>>>> >> >>>>> >> >>>>> On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian < >> >>>>> >> >>>> tere...@tmbsw.com> >> >>> >> >>>> wrote: >> >>>>> >> >>>>> This is helpful. Thank you for posting this, Carlos. I have a >> >>>>>> >> >>>>> couple >> >>> >> >>>> of >> >>>> >> >>>>> related questions. >> >>>>>> >> >>>>>> The config files I've used iOS and Android are significantly >> >>>>>> >> >>>>> different >> >>> >> >>>> for >> >>>>> >> >>>>>> the same project. Is combining everything for all platforms into one >> >>>>>> config.xml recommended? >> >>>>>> >> >>>>>> What cordova commands cause the www folder to be copied to a >> >>>>>> >> >>>>> platforms >> >>> >> >>>> directory? My workflow for iOS/Xcode is typically (similar for >> >>>>>> Android/Eclipse): >> >>>>>> >> >>>>>> - add/build iOS platform using cordova >> >>>>>> - edit, build, test iteratively in Xcode using platforms/ios >> >>>>>> >> >>>>> directory >> >>> >> >>>> Xcode doesn't copy from the outer www directory when it builds. >> >>>>>> >> >>>>> Should >> >>> >> >>>> it? >> >>>>> >> >>>>>> All of the files added to the Xcode project are in the platforms/ios >> >>>>>> directory. >> >>>>>> >> >>>>>> -Terence >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On 6/4/2014 10:10 AM, Carlos Santana wrote: >> >>>>>> >> >>>>>> I think regardless how much sugar we use to make it easy, I think >> >>>>>>> >> >>>>>> the >> >>> >> >>>> under >> >>>>>>> the hood foundation/architecture should be something like: >> >>>>>>> >> >>>>>>> LocalProject/www/ >> >>>>>>> LocalProject/config.xml >> >>>>>>> LocalProject/package.json >> >>>>>>> LocalProject/node_module/.bin/cordova >> >>>>>>> >> >>>>>>> config.xml (manages the cordova app) >> >>>>>>> package.json (manages the cordova project) >> >>>>>>> >> >>>>>>> pacakge.json (will specify all dependencies and npm will take care >> >>>>>>> >> >>>>>> of >> >>> >> >>>> fulfill them) >> >>>>>>> { >> >>>>>>> cordova: ">3.6", >> >>>>>>> cordova-ios: "3.6.1", >> >>>>>>> cordova-android: "3.6.2", >> >>>>>>> cordova-plugin-device: "*", >> >>>>>>> cordova-plugin-file: "^0.2.4" >> >>>>>>> } >> >>>>>>> npm install will take care of making everything available locally. >> >>>>>>> >> >>>>>>> I know that we don't have plugins in npm, but something to think >> >>>>>>> >> >>>>>> about, >> >>>> >> >>>>> in >> >>>>> >> >>>>>> terms of just a secondary repository to download the files and >> >>>>>>> >> >>>>>> caching. >> >>>> >> >>>>> a global @cordova-cli, can be available like grunt-cli, to look >> >>>>>>> >> >>>>>> first >> >>> >> >>>> in >> >>>> >> >>>>> local directory (i.e. findup) >> >>>>>>> >> >>>>>>> like someone mentioned npm installs hooks can run the "cordova >> >>>>>>> >> >>>>>> platform >> >>>> >> >>>>> add" >> >>>>>>> >> >>>>>>> this way minimal set of files can be put a dev repo, and reproduce >> >>>>>>> >> >>>>>> by >> >>> >> >>>> another developer very easy both getting same resulting project. >> >>>>>>> >> >>>>>>> git clone https://github.com/myuser/cordovapp && cd cordovapp && >> >>>>>>> >> >>>>>> npm >> >>> >> >>>> install && cordova run android >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Tue, Jun 3, 2014 at 6:35 PM, Terence M. Bandoian < >> >>>>>>> >> >>>>>> tere...@tmbsw.com> >> >>>> >> >>>>> wrote: >> >>>>>>> >> >>>>>>> I still consider myself a relative newcomer to Cordova but, from a >> >>>>>>> >> >>>>>>>> development standpoint, it would be easiest for me if I could >> >>>>>>>> >> >>>>>>> manage >> >>> >> >>>> each >> >>>>> >> >>>>>> platform of a project independently - including plugins. Creating >> >>>>>>>> >> >>>>>>> a >> >>> >> >>>> parallel project to make sure that the plugins and Cordova base >> >>>>>>>> >> >>>>>>> don't >> >>> >> >>>> change for one platform while I work on another isn't ideal but it >> >>>>>>>> >> >>>>>>> isn't >> >>>>> >> >>>>>> completely unmanageable either. It just makes the workflow a >> >>>>>>>> >> >>>>>>> little >> >>> >> >>>> more >> >>>>> >> >>>>>> complex. >> >>>>>>>> >> >>>>>>>> -Terence >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 6/3/2014 7:12 PM, Michal Mocny wrote: >> >>>>>>>> >> >>>>>>>> We don't do platform-plugin version matching *at all* today. >> >>>>>>>> >> >>>>>>> Everyone >> >>>> >> >>>>> uses >> >>>>>>>>> the latest plugins and any platform version they want, and its >> >>>>>>>>> >> >>>>>>>> been >> >>> >> >>>> "fine". >> >>>>>>>>> So using different platform versions isn't as hard as you guys >> >>>>>>>>> >> >>>>>>>> are >> >>>> >> >>>>> making >> >>>>>>>>> it out to be. >> >>>>>>>>> >> >>>>>>>>> Still, I've already said its not necessarily a complexity that >> >>>>>>>>> >> >>>>>>>> needs >> >>> >> >>>> to >> >>>>> >> >>>>>> be >> >>>>>>>>> addressed in a world where you can create multiple projects and >> >>>>>>>>> >> >>>>>>>> use >> >>> >> >>>> --link-to or whatever, so long as your platforms aren't installed >> >>>>>>>>> globally. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Anyway, thanks for posting your instructions Brian/Tommy. As I >> >>>>>>>>> mentioned >> >>>>>>>>> it would be, thats a different workflow than we have now. I'm >> >>>>>>>>> >> >>>>>>>> going >> >>> >> >>>> to >> >>>>> >> >>>>>> sleep on it before I comment, but it certainly isn't just like >> >>>>>>>>> >> >>>>>>>> "You >> >>> >> >>>> know >> >>>>> >> >>>>>> how we do it today". >> >>>>>>>>> >> >>>>>>>>> -Michal >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams < >> >>>>>>>>> to...@devgeeks.org >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> I don’t think you really can forget about plugins for a second. >> >>>>>>>>> >> >>>>>>>>> In my personal opinion, the entire ./platforms folder should be a >> >>>>>>>>>> >> >>>>>>>>> build >> >>>>> >> >>>>>> artefact. If you want to freeze iOS, then use a branch or a new >> >>>>>>>>>> >> >>>>>>>>> clone >> >>>> >> >>>>> of >> >>>>>>>>>> the project. >> >>>>>>>>>> >> >>>>>>>>>> It’s not that I can think of no scenarios where supporting >> >>>>>>>>>> >> >>>>>>>>> multiple >> >>> >> >>>> platform versions would be needed, it’s just that I think it’s >> >>>>>>>>>> needlessly >> >>>>>>>>>> complex vs using a dev workflow to solve those problems. >> >>>>>>>>>> >> >>>>>>>>>> I already version cordova within a project… I have a local >> >>>>>>>>>> >> >>>>>>>>> version >> >>> >> >>>> of >> >>>> >> >>>>> cordova installed into ./node_modules for each project and use >> >>>>>>>>>> >> >>>>>>>>> Grunt >> >>>> >> >>>>> to >> >>>>> >> >>>>>> call ./node_modules/.bin/cordova rather than the global cordova >> >>>>>>>>>> >> >>>>>>>>> cli. >> >>>> >> >>>>> On 4 June 2014 at 9:46:29, Terence M. Bandoian ( >> >>>>>>>>>> >> >>>>>>>>> tere...@tmbsw.com) >> >>> >> >>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> 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 < >> >>>>>>>>>>> >> >>>>>>>>>>> to...@devgeeks.org> >> >>>>>>>>>>> >> >>>>>>>>>> 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 < >> >>>>>>>>>>>> tere...@tmbsw.com >> >>>>>>>>>>>> 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 <b...@brian.io> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>> mmo...@chromium.org> >> >>>>>>>>>>>>>>> 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 <b...@brian.io> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> wrote: >> >>>>> >> >>>>>> NIH: not invented here >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve < >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> agri...@chromium.org >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux <b...@brian.io> >> >>>>>>>>>>>> >> >>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> agri...@chromium.org> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux < >> b...@brian.io >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>
