On Sat, Feb 7, 2009 at 12:30 PM, Nick H. [email protected]
wrote:
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 D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com