incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Supporting multiple projects on iOS
Date Fri, 28 Sep 2012 10:42:00 GMT
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 <purplecabbage@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.mike@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.walczyszyn@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 <agrieve@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.johnson@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

Mime
View raw message