[rspec-devel] Back to one repository?
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>
> 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...
More information about the rspec-devel