[Rubygems-developers] gembundles

Austin Ziegler halostatue at gmail.com
Tue Mar 27 16:48:13 EDT 2007


On 3/27/07, Chad Woolley <thewoolleyman at gmail.com> 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 * halostatue at gmail.com * http://www.halostatue.ca/
               * austin at halostatue.ca * http://www.halostatue.ca/feed/
               * austin at zieglers.ca


More information about the Rubygems-developers mailing list