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?
--
Posted via http://www.ruby-forum.com/.
Stephen Tashiro 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.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
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.
On Mar 31, 2006, at 10:52 AM, Stephen Tashiro 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?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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.
On 2006-03-31 10:52:55 -0800, Stephen Tashiro <tashiro@zianet.com> 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?
Erik Hollensbe 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?
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"
$:.shiftThe 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?
On 2006-03-31 10:52:55 -0800, Stephen Tashiro <tashiro@zianet.com> said:
--
-- Jim Weirich
--
Posted via http://www.ruby-forum.com/\.
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.
On 2006-04-03 20:54:25 -0700, Jim Weirich <jim@weirichhouse.org> said:
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.