On Monday 12 September 2005 02:18 pm, Eric Hodel wrote:
> $ cat x.rb
> puts "rubygems: #{require 'rubygems'}"
> puts "active_record: #{require 'active_record'}"
> puts "required? #{defined? ActiveRecord}"
> puts "RubyGemsVersion: #{Gem::RubyGemsVersion}"
> $ ruby x.rb
> rubygems: true
> active_record: false
> required? constant
> RubyGemsVersion: 0.8.10

Thanks.  I took a bit to figure out, but here's what is happening.

Gem goes to load active_record and cannot find it, so it recognizes that there 
is an active_record file in a gem named 'activerecord'.  It actives the gem 
with autorequire enabled.  It then attempts to require the active_record file 
again, but since the gem was activated with autorequire, the file is already 
loaded by the activation step.  Since it is already load, require returns 
false.

We can fix this by turning off autorequire during the gem activation.  I am 
tempted to do this, but want some testing time to make sure we don't break 
something else.

> I also see this behavior when required files can't be loaded.
> Sparklines requires RMagick, but if RMagick isn't available (I moved
> it aside) then no LoadError is given.
>
> [11:16] drbrain@kaa$ irb
> irb(main):001:0> require 'rubygems'
> => true
> irb(main):002:0> require 'sparklines'
> => false
> irb(main):003:0> Sparklines.plot([1,2])
> NameError: uninitialized constant Sparklines
>          from (irb):3

Hmmm ... surprisingly disabling autorequire fixes this behavior too.  The 
original exception must not propagate out of the activation step.  This 
confirms my long held belief that autorequire is evil.

(I've CC'ed the rubygems list to make sure everyone there sees this as well).

Thanks for the feedback.

-- 
-- Jim Weirich    jim / weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)