On Fri, Jan 14, 2011 at 9:02 AM, Roger Pack <rogerdpack2 / gmail.com> wrote:
>> I'd like to drop gem_prelude down to 'require "rubygems"'. If you want, we can profile this against normal and pathological gem setups first.
>
>
> Perhaps another option would be trimming gem_prelude down "something like"

Your example would want to re-dispatch to "require" in the "after
loading RubyGems" case since RG redefines require, but I've considered
a similar change in JRuby myself.

To be honest, I think it was overreaching to have gems available with
default Ruby startup in the first place. In 1.8, users could run
without RubyGems if they wanted, avoiding the extra loaded code and
any startup hit. They could specify -rubygems or require it if they
really needed it. In 1.9, users have to opt *out* of loading (or out
of gem_prelude scanning gems), meaning that even if they never touch
the code and never use a gem, it's always there, always being loaded.

Now we have solutions like bundler that make it almost trivial to
package up an application plus its gems without loading RubyGems at
runtime at all.

I wish I would have been more active on ruby-core when the decision
was made to add gem_prelude, because I would have argued strongly
against it. I think Ruby's users would be best served by returning
RubyGems to an opt-in and eliminating gem_prelude altogether.

Caveat: Any lazy-loading mechanism is going to be a challenge to
support well in a concurrent environment. For example, if another
thread happens to hit the newly-defined (by RubyGems) require()
halfway through RG's loading, things could break badly. Of course,
doing concurrent requires is broken in general, so this is really no
different.

- Charlie