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? On Mar 12, 10:39 am, ChrisT <[email protected]> wrote: > 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! UseRails.rootinstead. > (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.rootRails.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 whileRails.rootis 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
