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
--
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
Bob Martens
2010-Mar-18 14:37 UTC
Re: When -exactly- does the Rails3 application get initialized?
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 <ccth...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.