[rspec-devel] Back to one repository?

David Chelimsky dchelimsky at gmail.com
Thu May 1 09:56:07 EDT 2008

On May 1, 2008, at 8:38 AM, Zach Dennis wrote:

> 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.

A separate app 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 ones).
> I don't know everything required for rspec-rails to be tested, but  
> it seems like this may be a viable approach. WDYT?

We currently have specs split between the example rails app and the  
rspec-rails/spec directories. That creates an unfortunate coupling to  
the example rails app to achieve the level of coverage we have. Some  
history - it started off that ALL of the specs were in the example  
rails app and none were in the rspec-rails directory. So we're part  
way where we want to be. I think we'd need to solve that problem  
before we could do something like this. But I'm open to it.

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

More information about the rspec-devel mailing list