A good system for $LOAD_PATH management?


#1

I see, by experiment, that one can maipulate $LOAD_PATH within a Ruby
program. The second edition of the Pixaxe book indicates that using
rubygems is a good way.

What are some examples of “best practices” for $LOAD_PATH management?


#2

Stephen T. wrote:

I see, by experiment, that one can maipulate $LOAD_PATH within a Ruby
program. The second edition of the Pixaxe book indicates that using
rubygems is a good way.

What are some examples of “best practices” for $LOAD_PATH management?

One idea: have a directory called ruby/prj/lib or some such, put it in
your $RUBYLIB env var so that it gets into $LOAD_PATH, and populate it
with symlinks to your development directories. This lets you code
against your development versions of your libraries without installing
them locally.

For example, I have a lib project called “wl”. The lib files live in
ruby/prj/wl/lib/wl/ and there is also ruby/prj/wl/lib/wl.rb. My lib dir
has these symlinks:

ruby/prj/lib/wl -> …/wl/lib/wl/
ruby/prj/lib/wl.rb -> …/wl/lib/wl.rb

Then, since ruby/prj/lib is on my $LOAD_PATH, I can simply do

require ‘wl’
require ‘wl/something’

as I develop against this library. These two lines work the same when
the library is truly installed on a user’s computer. (I’m using the
standard setup.rb for this one.)

If I want to try installing locally to make sure my code works against
installed versions of the library, I can just clear RUBYLIB in a
subshell.


#3

On Mar 31, 2006, at 10:52 AM, Stephen T. wrote:

I see, by experiment, that one can maipulate $LOAD_PATH within a Ruby
program. The second edition of the Pixaxe book indicates that using
rubygems is a good way.

What are some examples of “best practices” for $LOAD_PATH management?

Don’t.

I typically only add to $LOAD_PATH for tests, and very, very rarely
at that. Most of the time you don’t need to do it.

I do have my RUBYLIB set so that I can use current versions of my own
libraries over installed versions.


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com


#4

On 2006-04-03 20:54:25 -0700, Jim W. removed_email_address@domain.invalid said:

But this will not play nicely with RubyGems. You cannot assume that
you are the only one manipulating the load path array. If you blindly
shift directories off the end of the array, it is quite possible you
will shift off something added by someone else (e.g. RubyGems).

I’m using it with my gems, but that thought didn’t even cross my mind,
and is very valid. I’ll make a note to update my gems the next time I
have a free moment.

I’ve check the rails source and I didn’t see any examples of using
shift on the load path array. Are you sure they do this?

Actually, I believe I plucked it out of ActiveSupport, and that was
just a paraphrase at best.

Thanks, however, for pointing out the serious problem with that.


#5

On 2006-03-31 10:52:55 -0800, Stephen T. removed_email_address@domain.invalid said:

I see, by experiment, that one can maipulate $LOAD_PATH within a Ruby
program. The second edition of the Pixaxe book indicates that using
rubygems is a good way.

What are some examples of “best practices” for $LOAD_PATH management?

Rails handles this very well, I’ve duplicated it in my own projects and
have had great success.

What rails does is unshift onto the load path based on the directory of
the current file, require the files necessary, then shift that item off
the load path (to keep duplicate filenames from being improperly
loaded).

It looks something (although you may want to read the Rails source) like
this:

$:.unshift(File.dirname(FILE) + “/whatever”)
require “foo”
require “bar”
require “etc”
$:.shift

The nice thing about this situation is that you can easily re-require
whole projects in irb by loading the file that contains this statement,
and leave your environment effectively clean after you’re done.


#6

Erik H. wrote:

On 2006-03-31 10:52:55 -0800, Stephen T. removed_email_address@domain.invalid said:

I see, by experiment, that one can maipulate $LOAD_PATH within a Ruby
program. The second edition of the Pixaxe book indicates that using
rubygems is a good way.

What are some examples of “best practices” for $LOAD_PATH management?

Rails handles this very well, I’ve duplicated it in my own projects and
have had great success.

What rails does is unshift onto the load path based on the directory of
the current file, require the files necessary, then shift that item off
the load path (to keep duplicate filenames from being improperly
loaded).

It looks something (although you may want to read the Rails source) like
this:

$:.unshift(File.dirname(FILE) + “/whatever”)
require “foo”
require “bar”
require “etc”
$:.shift

The nice thing about this situation is that you can easily re-require
whole projects in irb by loading the file that contains this statement,
and leave your environment effectively clean after you’re done.

NO! DO NOT DO THIS!

Ok, I’ll calm down a bit.

But this will not play nicely with RubyGems. You cannot assume that you
are the only one manipulating the load path array. If you blindly shift
directories off the end of the array, it is quite possible you will
shift off something added by someone else (e.g. RubyGems).

If you add a temporary directory to the load path, you should remove it
explicitly by matching the name. Something like this would be better:

load_directory = File.dirname(FILE) + “/whatever”
$:.unshift load_directory
require ‘foo’
require ‘bar’
require ‘etc’
$:.delete load_directory

I’ve check the rails source and I didn’t see any examples of using shift
on the load path array. Are you sure they do this?


– Jim W.


#7

If you would like to see some serious $LOAD_PATH Kung-Fu, check out
Rolls.

http://roll.rubyforge.org
(sorry about the large graphic, I need to shrink that down some)

I don’t suggest using it for production use (yet), I’m still developing
it, but the current code works well enough.

T.