When -exactly- does the Rails3 application get initialized?

I’ve been fighting left and right with rails 3 and bundler. There are
a few gems out there that don’t work properly if the rails application
hasn’t been loaded yet. factory_girl and shoulda are both examples,
even on the rails3 branch. Taking shoulda as an example, when trying
to run rake test:units I get the following error:
DEPRECATION WARNING: RAILS_ROOT is deprecated! Use Rails.root instead.
(called from autoload_macros at c:/code/test_harness/vendor/
windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:40) c:/
code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/
autoload_macros.rb:44:in ‘join’: can’t convert #Class:0x232b7c0 into
String (TypeError) from c:/code/test_harness/vendor/windows_gems/gems/
shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in ‘block in
autoload_macros’ from c:/code/test_harness/vendor/windows_gems/gems/
shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in ‘map’ from c:/code/
test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/
autoload_macros.rb:44:in ‘autoload_macros’ from c:/code/test_harness/
vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/rails.rb:17:in
‘<top (required)>’

Digging a bit deeper into lib/shoulda/rails, I see this:
root = if defined?(Rails.root) && Rails.root
Rails.root
else
RAILS_ROOT
end

load in the 3rd party macros from vendorized plugins and gems

Shoulda.autoload_macros root, File.join(“vendor”, “{plugins,gems}”,
“*”)

So…what’s happening here is while Rails.root is defined, Rails.root
== nil, so RAILS_ROOT is used, and RAILS_ROOT==nil, which is then
being passed on to Shoulda.autoload_macros. Obviously the rails app
has yet to be initialized. With Rails3 using Bundler now, there’s been
some hubub over on the Bundler side about being able to specify an
order in which the gems are required, but I’m not sure whether or not
this would solve the problem at hand.
Ultimately my questions is this: When exactly does the environment.rb
file (which actually initializes the application) get pulled in? Is
there any harm to bumping up when the app is initialized and have it
happen before the Bundler.require line in config/application.rb? I’ve
tried to hack bundler to specify the order myself, and have the rails
gem pulled in first, but it doesn’t appear to me that requiring the
rails gem actually initializes the application.
As this line (in config/application.rb) is being called before the app
is initialized, any gem in the bundler Gemfile that requires rails to
be initialized is going to tank.

Auto-require default libraries and those for the current Rails

environment. Bundler.require :default, Rails.env

Anyone else with this? I’m running into a similar situation with
CarrierWave where during initialization (using unicorn for testing) I
can’t get it to load because Rails.root is nil and they can’t join nil
with a string.

Any help here would be greatly appreciated. How have others got around
this?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs