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

--
Posted via http://www.ruby-forum.com/.

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
$

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"

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

···

On Tue, Mar 15, 2011 at 9:29 PM, Alex Young <alex@blackkettle.org> wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert K. wrote in post #987714:

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:

···

On Tue, Mar 15, 2011 at 9:29 PM, Alex Young <alex@blackkettle.org> > wrote:

--
Alex

--
Posted via http://www.ruby-forum.com/\.