Proposal: require to return path to loaded file

If you’re doing anything at all involved with $LOAD_PATH, it can be a
right pain trying to track down which file was actually loaded. It would
really help debugging if require returned the full path to the file.

Would this break anything? Alternatively, is there any other way to get
at this information?

While I admit that I haven’t exactly tested it extensively, it’s about
as simple a patch as you can get. In 1.8.7-p302, it’s:

diff --git a/eval.c b/eval.c
index 7156c06…ca4d99b 100644
— a/eval.c
+++ b/eval.c
@@ -7455,7 +7455,7 @@ rb_require_safe(fname, safe)
break;
}
rb_provide_feature(feature);

  •           result = Qtrue;
    
  •           result = path;
          }
      }
    
    }

Running this gives (obviously):

$ ruby -e ‘p require “socket”’
“/home/alex/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/i686-linux/socket.so”

From a cursory inspection, it looks like the same idea ought to apply to
load.c in 1.9.2. Thoughts, anyone? Given that it’s this simple and I
can’t be the first person to have thought of it, is there a reason it’s
the way it is?


Alex

On Tue, Mar 15, 2011 at 9:29 PM, Alex Y. [email protected]
wrote:

If you’re doing anything at all involved with $LOAD_PATH, it can be a
right pain trying to track down which file was actually loaded. It would
really help debugging if require returned the full path to the file.

Would this break anything? Alternatively, is there any other way to get
at this information?

Somewhat similar

$ ruby19 -e 'l=$LOADED_FEATURES.dup;require “CSV”;puts($LOADED_FEATURES

  • l)’
    /opt/lib/ruby/1.9.1/forwardable.rb
    /opt/lib/ruby/1.9.1/English.rb
    /opt/lib/ruby/1.9.1/date/format.rb
    /opt/lib/ruby/1.9.1/date.rb
    /opt/lib/ruby/1.9.1/i386-cygwin/stringio.so
    /opt/lib/ruby/1.9.1/csv.rb
    $
   }

“/home/alex/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/i686-linux/socket.so”
Looks good to me. You only must be aware that you see only one file
but not all other files loaded along the way. But for that you could
use the approach from above.

From a cursory inspection, it looks like the same idea ought to apply to
load.c in 1.9.2. Thoughts, anyone? Given that it’s this simple and I
can’t be the first person to have thought of it, is there a reason it’s
the way it is?

Why not? +1

Kind regards

robert

Robert K. wrote in post #987714:

On Tue, Mar 15, 2011 at 9:29 PM, Alex Y. [email protected]
wrote:

If you’re doing anything at all involved with $LOAD_PATH, it can be a
right pain trying to track down which file was actually loaded. It would
really help debugging if require returned the full path to the file.

Would this break anything? Alternatively, is there any other way to get
at this information?

Somewhat similar

$ ruby19 -e 'l=$LOADED_FEATURES.dup;require “CSV”;puts($LOADED_FEATURES

  • l)’
    /opt/lib/ruby/1.9.1/forwardable.rb
    /opt/lib/ruby/1.9.1/English.rb
    /opt/lib/ruby/1.9.1/date/format.rb
    /opt/lib/ruby/1.9.1/date.rb
    /opt/lib/ruby/1.9.1/i386-cygwin/stringio.so
    /opt/lib/ruby/1.9.1/csv.rb
    $

Interesting. $LOADED_FEATURES contains mostly full paths on 1.9.2 on
my system, but for some reason “enumerator.so” is given as a relative
path. On 1.8.7 they’re all relative, so you can’t tell what came from
where without manually walking $LOAD_PATH.

However, even using $LOADED_FEATURES as here doesn’t get you all the
way, because you can’t tell whether “require ‘b’” loaded b.rb or a/b.rb
without looking at $LOAD_PATH anyway.

   }

“/home/alex/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/i686-linux/socket.so”
Looks good to me. You only must be aware that you see only one file
but not all other files loaded along the way. But for that you could
use the approach from above.

Yeah, without overriding require it would be tricky to handle nested
cases, but for my specific use case that’s not a problem :slight_smile:


Alex

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs