[ruby-core:43486] Re: [ruby-trunk - Feature #4523] Kernel#require to return the path of the loaded file

On Mar 19, 2012, at 10:16 AM, Alex Young wrote:
> On 19/03/12 11:58, Luis Lavena wrote:
>> On Mon, Mar 19, 2012 at 8:06 AM, Alex Young<[e-mail]>  wrote:
>>> On 18/03/12 10:22, nobu wrote:
>>>> 
>>>> 
>>>> Issue #4523 has been updated by nobu.
>>>> 
>>>> 
>>>> I don't think it's useful if it may return false.
>>> 
>>> 
>>> On the contrary - if it returns false, you know the set of loaded files
>>> hasn't changed.  You (should) know that no new ruby has been parsed.
>>> 
>> 
>> What if your require triggers more requires inside?  The usefulness of
> > you collecting the response of one require doesn't mean you have all
> > the files that were loaded.
> 
> 
> This is the sort of thing I have in mind:
> 
>  module CollectingRequire
>    def require( *args )
>      filename = super(*args)
>      __log( filename )
>      filename
>    end
> 
>    def __log(filename)
>      (@__loaded ||= []) << filename
>    end
> 
>    def all_loaded
>      @__loaded
>    end
>  end
> 
>  extend( CollectingRequire )
> 
>  require 'highline'
> 
>  all_loaded
>    # => [all the files]
> 
> That's the sort of arrangement I'd need; I'm sure there are uses which don't involve monkeypatching.
> 
> I could do just as well with a post-require hook of some sort, but that's way more intrusive.  If that's what's needed, though, I'm happy to take a look at an implementation.

There's an easier way that works without any monkey patching or new features.

ruby -e 'loaded = $LOADED_FEATURES.dup; require "highline"; p $LOADED_FEATURES - loaded'

>>>> What's the use case?
>>>> I agree that the way to know the loaded path would be useful sometimes,
>>>> but this doesn't seem nice.
>>> 
>>> The specific thing I was trying to do was gather all the required files into
>>> a SQLite database.  Then a later process with an overridden `require` can
>>> load *precisely* the same file content from that database, without
>>> ambiguity.
>> 
>> Are you trying to build a list of all the files that were require'd ?
>> 
>> If so, why not use $LOADED_FEATURES with at_exit?
> 
> Because when I opened this feature request a year ago $LOADED_FEATURES didn't seem to include full paths, so I didn't want to rely on it.
> 
>> $LOADED_FEATURES include full paths
> 
> Does it?  Is that now part of the spec?

Yes.

> Neither rubinius nor jruby seem to make that guarantee,

They do.

> nor is it true for 1.8.7.

1.9.1, 1.9.2 and 1.9.3 have been released since 1.8.7, so I don't know why you would check 1.8.7 for new features.  jruby and rubinius follow the 1.8 spec when run in 1.8 mode, and the 1.9 spec when run in 1.9 mode.

>  And if it is...
> 
> $ irb
> 1.9.3p125 :001 > $LOADED_FEATURES.first
> => "enumerator.so"
> 
> Is that a bug?

I would argue no as enumerator.so is a dummy require:

  rb_provide("enumerator.so");	/* for backward compatibility */

to allow old 1.8 programs to continue to require 'enumerator' which is now built-in in ruby 1.9.

>> so you can use that combined with $LOAD_PATH to determine the require itself.
> 
> I can, and do, already do something like this.  The point is that by adding this information to the API, I don't have to - I get a known-good value directly from where it's generated, rather than recreating it (and possibly screwing it up).  I'm sure I'm not the only one who'd find this handy.
> 
> If anyone can spot how this proposal can *possibly* be harmful, I'm all ears.  As far as I can see it's an unintrusive, useful improvement.

It only returns the filename directly loaded, not the complete set of files required, so can only return limited information.

It only returns the filename if this was the first time the file was required.  It feels bad that this feature would only work on the first require which the user may not be able to control.

It promotes needless monkey patching or overriding of require when there is a simple solution to retrieve the information you desire (the set of files loaded, per your example above).

For these reasons, I don't think it encourages good use of ruby.