dchelimsky at gmail.com
Mon Mar 29 16:04:47 EDT 2010
On Mar 29, 2010, at 2:48 PM, Ashley Moran wrote:
> Hopefully I'll get chance to finish Spork integration with RSpec 2 this weekend. I've got two questions...
> (1) What's the best way to merge my changes back in? My shockingly bad Git-fu has made it impossible to rebase on top of master. I suspect having a (now disabled) Textmate macro to clean EOL whitespace has not helped. I've restructured some code - I plan to do a proper refactoring when it all joins up (ie when I see Rails 3 working) but I'd rather get Spork merged as soon as it's runnable in case I make life even harder for myself.
How wide-reaching are your changes? i.e. how many files, etc?
> I know know that the Spork interface expects you to provide an argv and out/error streams when you call its DRb interface. It then calls the "CLI" interface to RSpec. This is one reason RSpec 2 integration is harder than I thought, because that RSpec API has been rewritten (and is much better now I've seen both). So...
> (2) Is there a stable API call we can settle on for this going forward? I was thinking along the lines of `Rspec.run(argv, err, out)` or `Rspec.run_command(argv, err, out)` or something. Any ideas?
This is an interesting catch 22. The dependency appears to be from Spork to RSpec (i.e. RSpec doesn't know about Spork), but RSpec needs to commit to an API so support Spork, which is very likely the only tool that needs this API.
I wonder if we got the dep backwards? i.e. why not have Spork expose and API and have RSpec hook into it?
> (2.5) Any reason why the new RSpec module is "Rspec" not "RSpec"? </grammarnazi>
AFAIK, autoloaders (like in Rails and Autotest), assume a CamelCase convention for class names, which RSpec violates, and Rspec adheres to. If I'm wrong about this, I'd prefer to make it RSpec, since that's the name of the book and all :) Anybody have insights/opinions on this?
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users