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?