Robert K. wrote in post #987714:
> On Tue, Mar 15, 2011 at 9:29 PM, Alex Young <alex / blackkettle.org>
> 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 :-)

--
Alex

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