> We are about to ship a version of Ruby with a built in package manager with
> the following property:
> Given a package X with dependency Y, attempting to load X might require
> dependency Z without any warning.
> There is literally no other distribution of anything that would not consider
> that property a major show-stopper. I am baffled about how this bug has
> existed in the tracker so long, is considered "normal" priority, and has now
> been bumped to 1.9.3 at the earliest.

True it does require Z if Z is the same gem as X but Z has version > X
It's inaccurate, and I agree it should be fixed.

Is there any other instance where it causes a problem except for when
you have differing versions of the same gem installed?

You know what really gets me, though...

If you are using rubygems and you have

gem1/lib/xxx.rb
  its contents are
     require 'yyy'

and

gem2/lib/yyy.rb

and

gem3/lib/yyy.rb

it will choose the yyy.rb of gem2 or gem3 *arbitrarily*

That's the one that really gets me.  Yikes.  The only work around is to add a

gem 'xxx' for *every gem you ever use* which clutters the code.

Oh and the fact that rubygems downloads and installs binary gems built
against 1.8 when I'm running 1.9

That one is also tough.

> ~/Code/tmp /master > irb
> ruby-1.9.2-head > require "action_dispatch"
>  => true
> ruby-1.9.2-head > Rack.release
>  => "1.2"

Forgive me for not being familiar with rack and activesupport, but
what gem is action_dispatch in and why is this "1.2" an error?

Thanks.
-r