thinking a bundled upgrade cli command in all the projects is a good idea... something that automates whatever we document in the upgrade guide
On Thu, Sep 27, 2012 at 6:58 PM, Jesse <purplecabb...@gmail.com> wrote: > Mis-understood some of the finer points, thanks for the clarification > and patience all. > > I agree that option 2 makes the most sense. > > On Thu, Sep 27, 2012 at 9:52 AM, Mike Reinstein > <reinstein.m...@gmail.com> wrote: >> an upgrade script would be really helpful as well. >> >> -Mike >> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn < >> piotr.walczys...@gmail.com> wrote: >> >>> As I suggested in the pull request comments, this would really make >>> sense to update bin/create script either by enhancing it with >>> additional argument to embed the CordovaLib with newly created >>> projects or even make this behavior a default one. >>> >>> p. >>> >>> 2012/9/27 Andrew Grieve <agri...@chromium.org>: >>> > Suppose you have 5 projects that depend on 2.1, and 3 that depend on 2.0. >>> > >>> > One big difference between the two options is that for the 2nd option, >>> > you'd have 8 copies of Cordova, whereas for the first option you'd have >>> > only two. >>> > >>> > I think getting the correct workflow set up with Xcode workspaces will be >>> > quite cumbersome though, and not something that will be easy for us to do >>> > with tooling. We'd pretty much have to rely on documentation to tell >>> people >>> > how to drag multiple projects into their own workspace. >>> > >>> > I think maybe another key point is that CordovaLib is really small, and >>> > will get even smaller if/when we remove the core plugins from it. In this >>> > model, the majority of the code will be pluginstalled into users' >>> projects >>> > anyways, so it won't be a bit deal to have a bunch of copies of >>> CordovaLib >>> > around. >>> > >>> > The model that pwalczyszyn is using is to copy the CordovaLib directory >>> > into each project's directory, similar to how we have a "cordova" >>> directory >>> > that we copy into it. Taken from his pull requests comments: >>> > >>> > MyProject >>> >> -- cordova >>> >> -- MyProject >>> >> ---- CordovaLib >>> >> ------ CordovaLib.xcodeproj >>> >> ---- Plugins >>> >> ---- Resources >>> >> ---- .... >>> >> -- MyProject.xcodeproj >>> >> -- www >>> > >>> > >>> > Having CordovaLib a sibling of Plugins does make sense in this model I >>> > think. Either that, or have it up one level. >>> > >>> > >>> > To implement this, we'll need to change our bin/create script to copy in >>> > the CordovaLib directory. Not too hard. >>> > >>> > For upgrades, how will we address this though? Just add documentation >>> > telling users to delete the old directory and copy over the new one? The >>> > steps would be: >>> > cp -r path/to/new/cordova/CordovaLib MyProject >>> > path/to/new/cordova/bin/update_cordova_subproject MyProject >>> > MyProject/CordovaLib >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Thu, Sep 27, 2012 at 10:16 AM, Dave Johnson <dave.c.john...@gmail.com >>> >wrote: >>> > >>> >> +1 >>> >> >>> >> On Thursday, September 27, 2012, Mike Reinstein wrote: >>> >> >>> >> > Agree on all points with Brian. >>> >> > >>> >> > On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux <b...@brian.io >>> <javascript:;>> >>> >> > wrote: >>> >> > >>> >> > > > Global dependancies? It's a library, why would you not be >>> dependent >>> >> on >>> >> > > it? >>> >> > > > >>> >> > > >>> >> > > We're talking about global deps vs local deps. Not whether or not >>> >> you'll >>> >> > > have a dependency! >>> >> > > >>> >> > > >>> >> > > > Standardize on the apis and not the files. >>> >> > > > >>> >> > > >>> >> > > Uh, ok sure, not sure I understand? >>> >> > > >>> >> > > It only takes a few weeks of ruby (and/or python) dev to see where >>> >> global >>> >> > > packages become ambushes for epic fail. Node learned from this and >>> >> > > explicitly created lexically scoped packages. Typically when you >>> ship >>> >> > > projects you want to have the dependencies bundled to minimize >>> issues. >>> >> > > >>> >> > > See http://en.wikipedia.org/wiki/Dependency_hell >>> >> > > >>> >> > > >>> >> > > Not to mention the extra complexity of #2, and multiple out of sync >>> >> > > > project issues. >>> >> > > > >>> >> > > >>> >> > > I do not see where this creates complexity. It reduces it. I have a >>> >> > project >>> >> > > that I want up-do-date. It has a dependency on 2.1.0. I have another >>> >> > > project I do not want to update running 2.0.0: no problem. If I >>> have a >>> >> > > global dependency: problem! >>> >> > > >>> >> > > The other issue here is the requirement of having your library >>> >> > > a separate concern for the end user project. When I want to build a >>> >> > project >>> >> > > from another repo it requires me to install the correct version of >>> the >>> >> > > dependency. With option 2 the library is a part of the project and >>> no >>> >> > > installer step is required. Again: reduced complexity. >>> >> > > >>> >> > > >>> >> > > >>> >> > > I originally moved the codebase to a library and created the >>> template >>> >> > > > over 2 years ago, so I may be blind to the benefits of #2, but to >>> me >>> >> > > > this makes our library become a boilerplate... am I wrong? >>> >> > > > >>> >> > > >>> >> > > Do not see how this is related either. >>> >> > > >>> >> > >>> >> >>> > > > > -- > @purplecabbage > risingj.com
