What about the potential duplication and conflict of versions? For example, if you multiple versions of a dependency installed as first-class gems, then other multiple (and possibly duplicated and conflicting) versions "bundled" in with another first-class gem, which ones "win"? What goes on the load path first? Does it depend on the circumstances (which one is loaded first)?
On 3/27/07, TRANS <[EMAIL PROTECTED]> wrote: > On 3/27/07, Austin Ziegler <[EMAIL PROTECTED]> wrote: > > On 3/25/07, TRANS <[EMAIL PROTECTED]> wrote: > > > While working on a integrated gembundles implementation. I figured out > > > a much better approach. Rather than have a separate gembundle format, > > > the standard gem can just have a third part. Ex. in some.gem: > > > > I'm still really not sure what you're trying to solve here that isn't > > solved by normal gem dependencies. > > The general use case is when you have an application that depends on > _many_ smaller packages. In my case, I am breaking Facets up into a > number of subprojects so that programmers have the option to use parts > of Facets independent of the whole. But Nitro uses Facets and Nitro > doesn't want the situation where dozens fo subpackages have to be > independently confirmed/downloaded/installed. They want ONE support > package and that's it. So how do I acheive both goals? Moreover, it > allows Nitro to to branch out to other libs, rather than depend on > Facets for everything. > > Also, bundles makes it easier to distribute an application on physical > media since everythng one needs can be in one package. > > Thridly, it puts us one step away from something like Klik or Jars for Ruby. > > T. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
