+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. > > >
