On Aug 28, 2010, at 23:45, Run Paint Run Run wrote:
> 
>>> 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).
> 
> Ah, OK. I thought I'd read about various libraries overriding `require`, and
> chaos resulting, but I can't find the thread again, so was possibly
> hallucinating.

Yes, I recall this thread... I don't know of any wide-spread use of the idea besides RubyGems.  I think it was a theoretical discussion.

> Theoretically, the presence of arbitrary objects in $LOAD_PATH breaks backward
> compatibility in that users may expect an Array of Strings. That's not a
> significant hurdle, however.

Yes.

How often do people use $LOAD_PATH besides printing it?

Perhaps an API to look up the path for a feature should be added alongside Kernel#require.

Something like this but with a non-terrible name:

look_up_path_for 'rake' # => /usr/local/lib/ruby/1.9.1/rake.rb

> In the proof of concept, the feature name may be an arbitrary object. I assume
> this is unintentional, mainly because it couldn't be used with the '-r' switch
> on the command-line.

It is unintentional.

> FWIW, I like this idea. A loader could generate a feature by compiling a
> third-party language on-the-fly. A GemMissing loader can sit at the head of
> load path, and automatically install gems from a local repository as
> needed. It's surely worth moving to the Features tracker and posting a pointer
> on ruby-talk to encourage more comments.