On Aug 28, 2010, at 23:45, Run Paint Run Run wrote:
>=20
>>> How confident are we that this API would be sufficient for replacing =
the
>>> multiude of require hacks present in the various RubyGems =
replacements?
>=20
>> 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).
>=20
> 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' # =3D> /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.

ok.=