On 3/27/07, Chad Woolley <[EMAIL PROTECTED]> wrote: > 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)?
I'm not saying that I buy Trans's reasoning for the need for this -- I've long thought that Facets should be a lot more granular than it is and a lot of the things that Trans has tried to push on Ruby that I have thought ill-considered over the last two years has been because Facets is not granular at all. That said, my understanding of what Trans wants to do is to bundle a group of gems in a gembundle. That bundle would then silently install the bundled gems as normal. To put it a bit more concretely, let's use a simple example: * I decide to make a Text bundle (version 1.0) that contains Text::Format (1.1) and Text::Hyphen (1.0) and Text::Reform (0.9). * I have Text::Hyphen 2.0 installed already. The Text bundle will install Text::Format 1.1, Text::Hyphen 1.0, and Text::Reform 0.9 and not touch Text::Hyphen 2.0. Therefore, I will have Text::Hyphen (1.0, 2.0) in my gem list. The only problem I can see is the case where I already have Text::Hyphen 1.0 installed. The concern here is that, for all of the problems that Mauricio points out with the gem authority issues and the mirrors, a bundle would represent a more direct way of inserting malicious code in place of a previously known good version UNLESS the bundle installer refused to install a version that was currently installed. I'm still not sold on the concept, but the trick here isn't to add yet another place for Ruby to look for code, but for a bundled distribution environment. -austin -- Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/ * [EMAIL PROTECTED] * http://www.halostatue.ca/feed/ * [EMAIL PROTECTED] _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers