Rails 3 Support/Design

Since Rspec-Rails 2 is specifically geared toward Rails 3, I’m
wondering why it doesn’t use railtie, the new generators, etc. Will
it stay this way or is it planned to support that?

On Thu, Jun 10, 2010 at 3:14 PM, geetarista [email protected]
wrote:

Since Rspec-Rails 2 is specifically geared toward Rails 3, I’m
wondering why it doesn’t use railtie, the new generators, etc. Will
it stay this way or is it planned to support that?

It does use the new generators, and we do have a railtie, but bundler
doesn’t support exposing the railtie in the :test group by default, so
if you do this:

group :test do
gem “rspec-rails”
end

… then you won’t see the rake tasks or the generators. I believe
this will be addressed in bundler before it goes final, at which point
we’ll rely only on the railtie.

Cheers,
David

Awesome. Thanks for the clarification!

On Thu, Jun 10, 2010 at 4:10 PM, David C. [email protected]
wrote:

gem “rspec-rails”
end

… then you won’t see the rake tasks or the generators. I believe
this will be addressed in bundler before it goes final, at which point
we’ll rely only on the railtie.

I’m not sure I see how bundler would address this, but couldn’t it be
addressed by breaking the stuff you need from rspec-rails in the
development environment into a separate rspec-rails-dev gem or
something like that.

Breaking up gems seems to have been a theme in the transition from
Rails 2 → Rails 3.

Just an idea

Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On Fri, Jun 11, 2010 at 11:17 AM, David C. [email protected]
wrote:

if you do this:
addressed by breaking the stuff you need from rspec-rails in the
I spoke w/ wycats about this issue at RailsConf and he agreed that railties in the test group should be exposed in development mode. RSpec won’t be the only tool that this impacts, nor would RSpec users be the only people.

That all make sense?

Well if it makes sense to you and Yehuda, that’s all that matters.
I’m still trying to get my head around the idea of bundler loading
part of a gem, but that’s probably cuz I really haven’t dug into how
bundler really works.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On Jun 11, 2010, at 10:56 AM, Rick DeNatale wrote:

group :test do
something like that.

Breaking up gems seems to have been a theme in the transition from
Rails 2 -> Rails 3.

Just an idea

And an interesting one at that, but I think it would add to more
confusion than not. Right now you just have to require ‘rspec-rails’ in
the Gemfile and it depends on rspec, which depends on all the other
gems. If we separated out a gem for generators/rake tasks, it would need
to be outside the test group, so you’d have one rspec gem in one group
and one in another.

I spoke w/ wycats about this issue at RailsConf and he agreed that
railties in the test group should be exposed in development mode. RSpec
won’t be the only tool that this impacts, nor would RSpec users be the
only people.

That all make sense?

David

On Fri, Jun 11, 2010 at 2:53 PM, Rick DeNatale [email protected]
wrote:

doesn’t support exposing the railtie in the :test group by default, so
I’m not sure I see how bundler would address this, but couldn’t it be

I spoke w/ wycats about this issue at RailsConf and he agreed that railties in the test group should be exposed in development mode. RSpec won’t be the only tool that this impacts, nor would RSpec users be the only people.

That all make sense?

Well if it makes sense to you and Yehuda, that’s all that matters.
I’m still trying to get my head around the idea of bundler loading
part of a gem, but that’s probably cuz I really haven’t dug into how
bundler really works.

I hadn’t considered that :slight_smile: I imagine it would have to load the gem.
I’ll discuss further w/ carlhuda and follow up when I know something
new.

On Fri, Jun 11, 2010 at 5:24 PM, David C. [email protected]
wrote:

It does use the new generators, and we do have a railtie, but bundler

And an interesting one at that, but I think it would add to more confusion than not. Right now you just have to require ‘rspec-rails’ in the Gemfile and it depends on rspec, which depends on all the other gems. If we separated out a gem for generators/rake tasks, it would need to be outside the test group, so you’d have one rspec gem in one group and one in another.
I hadn’t considered that :slight_smile: I imagine it would have to load the gem.
I’ll discuss further w/ carlhuda and follow up when I know something
new.

Remembering back to my conversation with Yehuda, the idea was that the
rake command and script/rails g script need bundler to load gems in
the test group in order for gems like cucumber-rails and rspec-rails
to expose tasks and generators via a railtie. So it’s not a bundler
issue, but a rails issue. In fact, there’s a rails ticket, to which
I’ve added a comment that looks suspiciously like the first sentence
in this paragraph.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3774-gem-generators-are-not-found-by-scriptgenerate#ticket-3774-3

Cheers,
David