On Sat, Feb 7, 2009 at 12:30 PM, Nick Hoffman <n...@deadorange.com> wrote: > For a while now, I've had the following in config/environment.rb : > > config.gem 'haml' > config.gem 'rspec', :lib => 'spec' > config.gem 'rspec-rails', :lib => 'spec/rails' > > I just tried running the Rails console in production mode, and this warning > occured: > > irb: warn: can't alias context from irb_context. > > After some googling, I learned that the gem deps on rspec and rspec-rails > are causing that warning. When I remove those two gem deps from > environment.rb , the warning disappears. > > With that said, I'm wondering what the accepted way to setup gem > dependencies on rspec and rspec-rails is. Should one not bother? Should the > "config.gem" lines go in config/environments/test.rb ?
Rails config.gem has never seemed to work 100% with libraries that shouldn't be loaded in all environments. With that said, I point you to the wiki: http://wiki.github.com/dchelimsky/rspec/rails-with-rspec-gems If you try to use the rake tasks to find gem dependencies for your app, it will not list them by default unless you set RAILS_ENV=test. ie: RAILS_ENV=test rake gems IMO, running "rake gems" should tell you the configured gems for *everything*, and it should say what environments a particular gem is required. It kind of defeats the purpose if I have to be so specific when asking the "rake gems" task what gems the application relies on. I've haven't successfully gotten all of the rake tasks for gems to work 100% in the test environment. For the most part the "gems" and "gems:unpack" do function. You can successfully bypass cofnig.gem and the associated rake tasks by using "gem unpack". ie: cd vendor/gems ; gem unpack rspec ; gem unpack rspec-rails Personally, I put rspec and rspec-rails in vendor/plugins, even if it's just using "gem unpack" to put them there. It makes easier to upgrade to recent changes in rspec/rspec-rails in order to try out bug fixes, or take advantage of new features. Basically you've got options. I'd recommend gem unpacking into vendor/gems or vendor/plugins. I don't see an advantage at this point of using config.gem since it doesn't work 100% of the time, and it doesn't work necessarily as it should (of course IMO), -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
