From: Eric Hodel <drbrain@...7.net>
Date: 2011-01-25T04:07:37+09:00
Subject: [ruby-core:34838] Re: Fwd:  Re: Avoiding $LOAD_PATH pollution


On Jan 12, 2011, at 17:00, Jonas Pfenniger (zimbatm) wrote:

> 2011/1/9 Eric Hodel <drbrain@segment7.net>:
>>> But I think another hidden goal of this proposal is to not touch
>>> #require, or at least avoiding the necessity of rubygems to override it
>>> with it's own version. Would you be interested if I come up with a
>>> solution in that area ?
>> 
>> Yes!
> 
> Hi Eric, sorry for taking so long. I tried to come-up with various
> solutions and am afraid there is no clean-one that doesn't break
> backward-compatibility.

Sorry my response came so late, I got distracted.

> == Backward-compatible hack
> 
> The simplest way to fix this without breaking backward compatibility,
> is to introduce a second method with signature (naming is bad):
> 
>  Kernel.require_search(feature) -> path | nil
> 
> On #require, if no path is found, it will fallback on this method, if
> it exists.

This does not behave in a way that RubyGems can use it.

RubyGems needs to be able to insert a load path before the system load paths so that rubygems-provided features may override built-in features.

By your description, with this patch if I gem 'rdoc' then require a file I will always get the built-in rdoc (or worse, a mix of the two if there are new files added to the gem).

> This means that rubygems and any other package-managers can
> fight over this method, and leave #require alone. If they want to
> change $LOAD_PATH for future requires, then it's fine too.

I am looking for a solution that removes the need to override a method instead of one that simply changes which method to override.

> Patch is under construction.
> 
> == Clean solution ?
> 
> I'd like to restore the feature / filename separation to make things a
> bit simpler in future ruby versions. But this emails needs to get out,
> so the rest of for another episode.
> 
> Cheers,
>  zimbatm
>