[rspec-devel] Back to one repository?
dchelimsky at gmail.com
Sat Apr 19 04:59:51 EDT 2008
On Apr 18, 2008, at 6:27 PM, Pat Maddox wrote:
> Brian, Alex Chaffee and I were talking about the repository layout
> just now. Alex pointed out that there's a lot of overhead when using
> the rspec project...
Alex and I had an interesting conversation about this last summer at
the Agile conference. My recollection is that, at that time, his
primary concerns were about the object structure and life-cycle - that
it was difficult to understand when things went wrong or how to extend
it. I think we addressed a lot of his concerns with the major
refactoring effort that Brian and Aslak undertook last fall, but there
is certainly more work to do. I'll follow up on some thoughts about
that in a separate thread.
The point is that my experience thus far is that if Alex is having
trouble with something, it's probably because it's a serious pain in
the ass :)
> I've written a bunch of rake tasks to reduce
> that, but even with those there's overhead. And as we figure out more
> tasks, we'll have to write more rake tasks to automate some of the
Excellent point. Clearly this is an unfortunate maintenance burden.
> For example, if you git:pull and there's a conflict, you have
> to go resolve the conflict and continue the rebase. Does it make
> sense to write a git:continue command that will examine any repos that
> had a conflict and are in need of a rebase continue? I'm not sure at
> this point, but it's one of many potential questions.
> Alex suggested that we go back to one repository, and change the
> plugin installation process. Basically the only reason the repos are
> split right now is because there's no way to check out directories,
> and we want people to easily install the rspec and rspec-rails
That's not the only reason. With one repo and the rspec and rspec-
rails directory up at the root level, developing rspec-rails is a
PITA. We had rake tasks that copied those two directories down to the
example rails app. I had tried to make that work w/ symlinks but found
that the generators did not work when I did that. Not sure if that's a
rails issue or an rspec issue, but either way it is an unresolved issue.
When we had the rspec_on_rails repo only available down below the
rails app we got a number of complaints of the low visibility. People
wanted to grab http://svn.rubyforge.org/rspec/rspec_on_rails instead
With the repos separated out, the rspec and rspec-rails repos have
high visibility, are conceptually decoupled, AND can just be installed
where they need to be for development. These are the pros that must be
weighed against the cons of developers/contributors having to managing
We also need to consider the Ruby developer who doesn't use rails.
We'd be forcing that user to clone a bunch of stuff they don't need.
I'm not sure how important an issue that is when weighed against
everything else, but it is certainly a consideration.
> What if instead of separate repos, we had people put the entire
> codebase under vendor/rspec? Then they could run a script like
> vendor/rspec/install_plugins that would export the rspec and
> rspec-rails dirs to vendor/plugins.
> I realize there will probably be some apprehension given that David
> did a lot of work to split the repos in the first place,
> and the
> headaches over the past couple days, but I think it's a very good idea
> that's worth considering.
> If nothing else, we should keep it in mind
> over the next couple weeks, and see what growing pains we experience
> that might be avoided by a unified repo.
I agree we should keep an eye on this. I have a lot of reservations,
but remain open to the discussion.
Another consideration is that separating them out has the effect, IMO,
of reducing the binding of rspec to rails development. There is a
world of users who believe that rspec is a rails development tool.
While I'm proud of the fact that rspec-rails has become a serious
player in the rails space, I'm also excited to see it being used in
A shining example, even though they're not using our rspec library
(for good reason - it uses advanced language features that are not
available in the early phases of the development of a language
implementation) is rubinius. What they are doing with rspec is
absolutely astounding. Keeping rspec core as a separate repo increases
the likelihood of more exciting developments like this outside the
So there are a lot of things to consider here. Looking forward to
hearing more thoughts on this.
More information about the rspec-devel