Question

today i was facing a strange problem:
got a ‘missing method’ error on a module, but the method was there and the file where the module was defined was required. After some searching i found a circular dependency, where 2 files required each other, and now i assume ruby silently aborts circular requires.

---

Edit Begin: Example

File ‘a.rb’:

require './b.rb'

module A
    def self.do_something
        puts 'doing..'
    end
end

File ‘b.rb’:

require './a.rb'

module B
    def self.calling
        ::A.do_something
    end
end

B.calling

Executing b.rb gives b.rb:5:in 'calling': uninitialized constant A (NameError). The requires have to be there for both files as they are intended to be run on their own from command line (i ommitted that code to keep it short).
So the B.calling has to be there. One possible solution is to wrap the requires in if __FILE__ == $0, but that does not seem the right way to go.

Edit End

---

to avoid these hard-to-find errors (wouldn’t it be nicer if the require threw an exception, by the way?), are there some guidelines/rules on how to structure a project and where to require what? For example, if i have

module MainModule
  module SubModule
    module SubSubModule
    end
  end
end

where should i require the submodules? all in the main, or only the sub in the main and the subsub in the sub?

any help would be very nice.

Summary

An explanation why this happens is discussed in forforfs answer and comments.

So far best practice (as pointed out or hinted to by lain) seems to be the following (please correct me if i’m wrong):

1. put every module or class in the top namespace in a file named after the module/class. in my example this would be 1 file named ‘main_module.rb.’
   if there are submodules or subclasses, create a directory named after the module/class (in my example a directory ‘main_module’, and put the files for the subclasses/submodules in there (in the example 1 file named ‘sub_module.rb’). repeat this for every level of your namespace.
2. require step-by-step (in the example, the MainModule would require the SubModule, and the Submodule would require the SubSubModule)
3. separate ‘running’ code from ‘defining’ code. in the running code require once your top-level module/class, so because of 2. all your library functionality should now be available, and you can run any defined methods.

thanks to everyone who answered/commented, it helped me a lot!

Answer 1

After asking about this on the Ruby mailing list a while back, when I used to have a file in my libraries just for requiring things, I changed to these two rules:

1. If a file needs code from another in the same library, I use require_relative in the file that needs the code.

2. If a file needs code from a different library, I use require in the file that needs the code.

As far as I understand it, Ruby requires in the order it is asked to, and so it doesn’t matter about circular dependencies.

(Ruby v1.9.2)

In answer to the comment about the example showing circular dependency problems:

actually, the problem with the example isn’t that the requires are circular, but that B.calling is called before the requires have completed. If you remove the B.calling from b.rb it works fine. For example, in irb without B.calling in the code file but run afterwards:

$ irb
require ‘/Volumes/RubyProjects/Test/stackoverflow8057625/b.rb’
=> true
B.calling
doing..
=> nil