cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: adding platforms to npm for dependency sanity
Date Wed, 04 Jun 2014 23:07:24 GMT
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. 

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.



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 <terence@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 <agrieve@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 <csantana23@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 <  
>>>>>  
>>>> terence@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 <  
>>>>>>>  
>>>>>> terence@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 <  
>>>>>>>>> tommy@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 (  
>>>>>>>>>>  
>>>>>>>>> terence@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 <  
>>>>>>>>>>>  
>>>>>>>>>>> tommy@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 <  
>>>>>>>>>>>> terence@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 <  
>>>>>>>>>>>>>>> mmocny@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 <  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>> agrieve@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 <  
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> agrieve@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  
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>  


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message