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 Thu, 27 Sep 2012 10:34:17 GMT
> 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.

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