[ruby-core:31910] Re: Avoiding $LOAD_PATH pollution

On Aug 28, 2010, at 19:30, Run Paint Run Run wrote:
> 
>> The lookup object pushed onto $LOAD_PATH must respond to #path_for.  The
>> feature being required (file name) will be passed in by Kernel#require.
> 
> Given the #to_path protocol, I suspect #path_for is a little too
> similar. Perhaps #require_path_for / #path_for_require ?

I don't care about the name.  I care about the protocol.  (feature name in path/nil/true/false out).

>> if RUBY_VERSION > '1.9' then
>>  $LOADED_FEATURES << path
>> else
>>  $LOADED_FEATURES << File.basename(path)
>> end
> 
> How about appending the absolute path under 1.9?

Pay no attention to the man behind the curtain!

If my proposal is implemented in 1.9 lib/fancy_require.rb need not exist.  lib/fancy_require.rb only has to be functional enough to be a proof of concept.  I only implemented enough of Kernel#require to be minimally compatible.  I know there are edge cases I'm ignoring.

Use this code at your peril!

> Say we had a loader object that allowed feature names to be given in
> Base64, e.g. `require "bm9rb2dpcmk=\n" would be equivalent to `require
> "nokogiri"`. Our loader object would decode the feature name, but
> would then want to allow other loader objects, such as RubyGems, to
> derive the feature's path. From what I gather, because fancy require
> does not recurse with the path it obtains from the loader object, the
> loader object would have to handle this recursion itself. In our
> example, the loader would call `require` with the decoded feature
> name, then return `nil` when re-entered. I'm not sure how I feel about
> this.

See lib/fancy_require/rubygems.rb.  It alters $LOAD_PATH to contain only the items after the look-up object then calls require again and returns true/false if the restricted $LOAD_PATH require was successful.

I can't think of a solution that would be as simple as a recursive require.

Some API to assist in manipulating $LOAD_PATH might be nice, or Kernel#require could accept a $LOAD_PATH override to use for the recursive call (require 'some_feature', %w[lib ext test]).

I don't think additional API is required as implementing a $LOAD_PATH look-up object would be a rare thing and it's ok if rarely-done things are a little difficult.

> Anyway, in principle at least, this could be used to commoditise RubyGems, right?

Correct, but it's more expansive than making RubyGems integration simple.  With the true/false return from #path_for you could create a $LOAD_PATH look-up object that loads features out of an archive.

> MRI would push a loader object onto the load path that translated feature names to gem paths, allowing RubyGems to be just another feature loader.

If my proposed API were implemented gem_prelude could be stripped down to code similar to Gem::LookUp in lib/fancy_require/rubygems.rb.  RubyGems loading could be delayed until absolutely necessary.  (It would work just like 1.8 but without the need to require 'rubygems' to use a gem-installed feature.)

> Then, a warning could be issued for re-defining Kernel.require, so as to encourage the use of this API instead.

This would be nice but is not necessary.  I think documentation would be sufficient.

> How confident are we that this API would be sufficient for replacing the multiude of require hacks present in the various RubyGems replacements?

I know of no successful RubyGems replacement that alters Kernel#require (rvm, bundler, isolate depend on RubyGems, RubyOpals never got off the ground, RPA is long dead).

urirequire could use #path_for, does that count?

http://fhwang.net/2005/11/01/urirequire-I-got-yer-Web-2-0-right-here