From: Eric Hodel <drbrain@...7.net>
Date: 2011-01-09T11:09:52+09:00
Subject: [ruby-core:34264] Re: Avoiding $LOAD_PATH pollution

On Jan 8, 2011, at 12:08, zimbatm ... wrote:
> I've been thinking about this a little bit for the past few days. Here 
> is what I think actually.
> 
> First of all, I think it's a good framework for experimentation, require 
> & friends never seemed to be totally right to me either, so it's nice to 
> have an initiative to rework some bits of it.
> 
> There is this perceived notion that $LOAD_PATH is polluted. But by 
> shifting some part of it into sub-objects, it is only hiding a part of 
> the information, making it necessary to resort to a new API to access 
> it.

Yes, this is a problem with my proposal.  A method to find a file on $LOAD_PATH like Gem.find_files may be a solution.

> Agreed, this could allow for a dynamic $LOAD_PATH, but in the 
> current situation, all that rubygems does, is activate the gems, and 
> push then on it's own internal $LOAD_PATH, right ? So we would have:
> 
> ['.../1.9', '.../site_ruby/1.9', '.../vendor_ruby/1.9', [ all the 
> activated rubygems ]]

Yes (but activated rubygems paths come before installed ruby paths)

> 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!