[rspec-devel] Back to one repository?

Zach Dennis zach.dennis at gmail.com
Thu May 1 09:38:15 EDT 2008

On Thu, May 1, 2008 at 6:06 AM, Wincent Colaiuta <win at wincent.com> wrote:

> Disclaimer: I've submitted a few patches to RSpec but I can't claim to be
> a heavyweight participant in the development process. So bear in mind that
> my perspective might not might be as well-informed as that of others, but
> here are my thoughts anyway.
> Let's think for a moment about who our target audiences are:
> 1. Vanilla RSpec users
> These users want to be able to checkout just the RSpec code, so it makes
> sense that it live in its own repository.
> 2. Rails RSpec users
> These users want to be able to checkout this and the RSpec code, so again
> it makes sense that it live in its own repository.
> 3. People hacking on RSpec itself
> It's for this group that rspec-dev.git exists, and it exists (or _should_
> exist) for the sole purpose of providing a convenient way of doing the
> "meta" tasks involved in RSpec development: ie. testing the three main parts
> of RSpec, setting up the example Rails app, packaging releases and so forth.
> If something about rspec-dev.git is starting to feel like a PITA then it's
> obviously not fulfilling its purpose of "providing a _convenient_ way..."
> 4. Users of the TextMate bundle
> Obviously, these are members of groups 1, 2 and 3, and need this to live
> in a separate repo for installation purposes.
> As I see it, rspec-dev.git should be almost static: once it's set up right
> there should be very few commits to it and there should be very little
> ongoing maintenance work on it.
> The optimal workflow as I envisage it is the following.
> - Have the developer clone the three or four repos, all in the same
> directory; ie.
> git clone ../path/to/rspec-dev.git
> git clone ../path/to/rspec.git
> git clone ../path/to/rspec-rails.git
> git clone ../path/to/rspec-tmbundle.git
> This is a once-off set-up and doesn't really justify having a Rake task
> IMO.

+1 to this.

> The idea of having multiple git repos nested inside a master repo makes me
> feel decidedly uncomfortable. Submodules is the only "supported" way of
> doing that, and it was tried and rejected because the submodule system is
> really designed for a different type of problem than the one RSpec is trying
> to solve. Nesting repos inside one another sets off alarm bells: if they
> really are _that_ interdependent then why do we have separate repos in the
> first place? But we want separate repos for ease of end-user consumption, so
> doesn't that mean that we haven't really achieved a sufficient degree of
> independence?
> You should be able to work in these repositories independently of one
> another without having to worry about too many meta issues. ie. if you have
> a bug to solve in "rspec" you should be able to work inside that repository
> and not have to think about the others. Only at the end of the process do
> you worry about the "meta" issue of running the granddaddy pre_commit task
> in rspec-dev.
> - Running the spec suite
> You should be able to run the spec suite for each of the repositories
> independently of the others. ie. you should be able to cd into the rspec
> clone and do a "rake spec" or "spec spec" (why is it "spec spec/spec?").
> Likewise, you should be able to cd into the rspec-rails clone and do "rake
> spec". Where should the example Rails app go? Evidently inside rspec-rails,
> ignored appropriately using .gitignore, and with symlinks to the relevant
> bits. Putting the rspec-rails repo _inside_ the Rails app just seems wrong.
> If the symlink thing doesn't work (as David indicates) then it's a bug in
> Rails, I suspect, and should be fixed, but in the meantime a simple Rake
> task should suffice to do a temporary copy instead of a symlink.

Micah Alles from Atomic Object wrote a tool called foundry last year
(although I see on rubyforge it never released any files), but I have a copy
of it from him that I've been using personally for plugin testing. It allows
you to test plugins against any version of Rails. I wonder if this would
work well for rspec-rails. It basically works by creating a cache of Rails
versions and a Rails application for each version.

You can go into the directory of the plugin in question and run "foundry
test" or "foundry test 2.0.2" or "foundry test edge" (you get the idea) and
it will copy that plugin into the rails application for each version it is
going to test it against.

I've recently modified my foundry to support a .foundry file which gives you
before/after commands so you can copy over required application files. For
example I have spec/rails_root/ which has some app/controllers in order to
test a Selenium plugin and I have a before command which tells it do copy
over those files into the example rails application app/controllers/*
directory. It also is told how-to start selenium before the tests run and
stop it after its done.

The advantage of this is that you get to stop worrying about carrying around
a full fledge Rails application inside your rspec-rails repository, but it's
still super easy to test against Rails (all versions or just specific

I don't know everything required for rspec-rails to be tested, but it seems
like this may be a viable approach. WDYT?

Zach Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080501/f967ce8b/attachment.html>

More information about the rspec-devel mailing list