From: Evan Phoenix Date: 2010-04-21T01:42:09+09:00 Subject: [ruby-core:29669] Re: [Bug #3140] gem activation has changed between 1.8 and 1.9 Any comment on this change? This will mean that there is a custom require defined in prelude and thus always used. If there is no comment, I'll move forward with committing it. - Evan On Apr 15, 2010, at 12:17 PM, Rich Kilmer wrote: > Well that's basically option A. That custom require will be in the > LoadError call stack. The only way to get rid of that is to do > something in load.c. I would still be an advocate for option C > (hook). Can anyone from core respond to that idea? Note that Evan's > fix is a solution though. > > On Thu, Apr 15, 2010 at 2:08 PM, Evan Phoenix wrote: >> >> On Apr 14, 2010, at 8:36 PM, Rich Kilmer wrote: >> >>> I wrote this original code in gem_prelude. >>> >>> The intent of this was threefold: >>> >>> 1) Make RubyGems packaged files accessible with require/load in 1.9 >>> without having to require 'rubygems' >>> 2) Minimize startup time (don't load the full rubygems library if its >>> not going to be used) >>> 3) Load rubygems proper if need be. >>> >> >> >>> I would prefer C. I know we don't have a lot of time before 1.9.2 but >>> if we get our ducks in a row we can make this work...it does need to >>> be fixed. >> >> I've gone ahead and implemented an option D, which is very similar to the original suggestion made for RubyGems back in 2007 (blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12792). >> >> This moves the RubyGem custom require into the prelude and triggers the full loading of RubyGems itself if the normal require raises a LoadError. It fixes the problem because the highest version gems are no longer pushed on $LOAD_PATH, allowing RubyGems to activate gems and the proper dependencies. >> >> This isn't as nice as Rich's suggestions, but it's possible to do easily without changes load.c. >> >> I've attached the patch for comment. >> >> Thanks! >> >> - Evan >> >> > >