[Rubygems-developers] uberRequire hack in place

Richard Kilmer rich at infoether.com
Sat Aug 28 11:49:56 EDT 2004


Ok...i checked in all this stuff per chad.  It should still work with
existing stub files, but from now out, stubs are not needed.  The issue here
remains the RUBYOPT thing...having to have rubygems working in order for
everything to work.  I did add that clever thing that was brought up ever so
far back that creates an ubygems.rb file in the lib dir...so you can tell
folks they need to do:

set RUBYOPT="rubygems"

Which is nicer than 'rrubygems'.  Now, on the win32 installer, if we are
bundled, we can have that installer create the RUBYOPT env variable.  We
could have the rubygems installer let folks know that they need to set this
too.  There is likely a win32 api for setting and ENV variable...we could
use that in the install.rb file if folks use the install.rb file...

Anyway, this RUBYOPT thing is necessary to make rubygems really transparent,
but we need to optimize our code to make sure that its as fast as possible.
One thing I was thinking on the 'rubygems/specification.rb' file is to
'require' it only when needed.  We would need to go through all the methods
and put it in the ones that could load it.  That gets our load time down to
almost nothing.

Also, the require_gem method's functionality has been moved to a
Gem.activate method.  This method follows the signature of the require_gem
except a manditory second param is a boolean which determines whether to
autorequire or not.  This is to ensure that if you did:

require 'jabber4r/jid'

It would not autorequire everything in the jabber4r gem and then if you did:

require_gem 'jabber4r'

Even though the gem is already loaded (because the first call did that) the
require_gem autorequires the rest of the stuff.  This was an edge case I
figured out after doing some testing.

-rich




More information about the Rubygems-developers mailing list