I voted in favour of it, but unless one can point out a
very good argument against it, I'd rather see this functionality being taken over in require itself. If you make a library out of various files with some requiring others, you shouldn't have to worry about where the program that uses the library will sit in the directory tree, or about whether the library is put in a standard place, but only about the relative position of the different library files.
Christophe Grandsire.
This is one of the worst things about #include -- and I *really* don't want to see it in Ruby.
Doing this sort of thing will encourage very bad project layout, just the sort of nonsense you see in C.
This is amuch requirest feature and Matz has turned it down regularly. It is actually not as useful as it first seems. Just the sames both Ruby/extensions and Ruby Facets has it as #require_local.
Also, I'm working on a project that I will release shortly that I think may make this issue go away for good.
This feature is very usefull for me whenever I have a multi-file script:
- On a Windows machine, one can run a Ruby script by double-clicking the file, by double-clicking the shortcut to it, or through context menus (e.g. right-click file "birthday.jpeg" then select from popup "Send To->publish_to_my_blog.rb"). In all cases, the Ruby program is called from the working directory, not from the script directory.
- With Ruby libraries counting in hundreds, it would be nice to require_local/require_relative, and not be worried about name clashes and accidentally including a random library (many libraries use "utils.rb" at some point). The danger is breaking current app when you download a library in the future.
- I would like 'require' to handle this:
require :relative=>"local_dir/utils.rb"
I was thinking about require recognizing somthing like the "home" indicator '~', or current indicator '.' for this. Maybe a minus sign since it looks a little like '~' too.
require '-/foo'
Trans
This discussion goes back a long way (see and the following thread). My stance is still the same: require should by default check the directory that __FILE__ is located in before checking the other directories in $LOAD_PATH. It should also be possible to override this behavior; this could be implemented by putting a special token at the beginning of $LOAD_PATH that represents the directory that __FILE__ is located in (or represents some other reasonable value if __FILE__ is "(irb)" or "(eval)" or similar).
At work I use requirelocal for this to avoid breaking libraries that depend on require's current behavior. The requirelocal code in RubyTreasures is still in production today.
Sorry, that last comment was from me.
-- Paul Brannan
Christophe Grandsire.
This is one of the worst things about #include -- and I *really* don't want to see it in Ruby.
Doing this sort of thing will encourage very bad project layout, just the sort of nonsense you see in C.
This is amuch requirest feature and Matz has turned it down regularly. It is actually not as useful as it first seems. Just the sames both Ruby/extensions and Ruby Facets has it as #require_local.
Also, I'm working on a project that I will release shortly that I think may make this issue go away for good.
This feature is very usefull for me whenever I have a multi-file script:
- On a Windows machine, one can run a Ruby script by double-clicking the file, by double-clicking the shortcut to it, or through context menus (e.g. right-click file "birthday.jpeg" then select from popup "Send To->publish_to_my_blog.rb"). In all cases, the Ruby program is called from the working directory, not from the script directory.
- With Ruby libraries counting in hundreds, it would be nice to require_local/require_relative, and not be worried about name clashes and accidentally including a random library (many libraries use "utils.rb" at some point). The danger is breaking current app when you download a library in the future.
- I would like 'require' to handle this:
I was thinking about require recognizing somthing like the "home" indicator '~', or current indicator '.' for this. Maybe a minus sign since it looks a little like '~' too.
Trans
This discussion goes back a long way (see and the following thread). My stance is still the same: require should by default check the directory that __FILE__ is located in before checking the other directories in $LOAD_PATH. It should also be possible to override this behavior; this could be implemented by putting a special token at the beginning of $LOAD_PATH that represents the directory that __FILE__ is located in (or represents some other reasonable value if __FILE__ is "(irb)" or "(eval)" or similar).
At work I use requirelocal for this to avoid breaking libraries that depend on require's current behavior. The requirelocal code in RubyTreasures is still in production today.
Sorry, that last comment was from me.
-- Paul Brannan