Hi 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. 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? (2.5) Any reason why the new RSpec module is "Rspec" not "RSpec"? </grammarnazi> Cheers Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran
On Mar 29, 2010, at 2:48 PM, Ashley Moran wrote:> Hi > > 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?> Cheers > Ashley > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Mar 29, 2010, at 1:04 PM, David Chelimsky wrote:> On Mar 29, 2010, at 2:48 PM, Ashley Moran wrote: > >> (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? >Isn''t CamelCase ([A-Z][a-zA-Z]*)+ If that''s the case, RSpec is fine. If not, then classes like CGI are also hosed. My $.02
On Mar 29, 2010, at 9:04 pm, David Chelimsky wrote:> How wide-reaching are your changes? i.e. how many files, etc?I think it''s only really the Runner stuff that''s changed. I''ve split it into InProcess and DRbProxy or some such... although I think really the DRb stuff belongs higher up.> 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?Yep catch 22 indeed! It''s a circular dependency. The way it works is Spork defines a DRb interface that takes arguments and the output streams. RSpec and Cucumber are both using this the same way. Seems like a stable interface so this dependency isn''t a problem. Prob is that then Spork needs to know what to do to use RSpec. Currently that involves (and Cucumber does the same) just passing the ARGV along. Which felt weird to write - because at the point you want to pass the ARGV along you''ve already parsed it to find out if it''s a --drb run*. But in theory you could pass anything as the args as long as the `Rspec.my_stable_api` call accepts it. One thought I had was that maybe the join should be separate... ie have independent gems rspec-core and spork, and spork-rspec, spork-cucumber, spork-testunit etc that depend on both. The prob with this is that while Spork is open to extension to new test frameworks, it doesn''t provide an easy way to register them before Spork loads**. Seems to come down to *is* Spork the only thing that would need this API? Would you maybe want to run specs directly in eg Redcar? If not then I think you''ve talked me round that the dep is backwards. But Spork would need refactoring for RSpec to be able provide its own Spork adapter. Any thoughts based on that?> 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?That''s why I asked now, incase RSpec 3 changes it again and the circular dep bites once more ;) Cheers Ash * I''m not sure it''s an easy one to solve because you have to figure out when to read in spec.opts. ** Sorta like how gem subcommands (eg gemedit) work. I''d love to know how that mojo does its stuff :) -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran
Ashley Moran wrote:> On Mar 29, 2010, at 9:04 pm, David Chelimsky wrote: > > >> How wide-reaching are your changes? i.e. how many files, etc? >> > > I think it''s only really the Runner stuff that''s changed. I''ve split it into InProcess and DRbProxy or some such... although I think really the DRb stuff belongs higher up. > > > >> 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? >> > > Yep catch 22 indeed! It''s a circular dependency. The way it works is Spork defines a DRb interface that takes arguments and the output streams. RSpec and Cucumber are both using this the same way. Seems like a stable interface so this dependency isn''t a problem. > > Prob is that then Spork needs to know what to do to use RSpec. Currently that involves (and Cucumber does the same) just passing the ARGV along. Which felt weird to write - because at the point you want to pass the ARGV along you''ve already parsed it to find out if it''s a --drb run*. But in theory you could pass anything as the args as long as the `Rspec.my_stable_api` call accepts it. > > One thought I had was that maybe the join should be separate... ie have independent gems rspec-core and spork, and spork-rspec, spork-cucumber, spork-testunit etc that depend on both. The prob with this is that while Spork is open to extension to new test frameworks, it doesn''t provide an easy way to register them before Spork loads**. > > Seems to come down to *is* Spork the only thing that would need this API? Would you maybe want to run specs directly in eg Redcar? If not then I think you''ve talked me round that the dep is backwards. But Spork would need refactoring for RSpec to be able provide its own Spork adapter. > > Any thoughts based on that? >When we added Spork support for Cucumber we made it a point to say that we were not adding Spork support exclusively but rather a general purpose DRb client for Cucumber. The idea was that someone could create a DRb based solution, other than Spork, and have it just work with the current Cucumber --drb flag. For example, one could imagine setting up a DRb server that would run testjour to speed up large cucumber runs. This same thinking could be applied to RSpec as well. RSpec provides a DRb client that has simple API which people can write various libraries for and only have to worry about STDIN, STDOUT, and args. Maybe we are fooling ourselves to think that other people may be writing these in addition to spork though. David raises an interesting question about if we got the dependency backwards. I''ve been thinking a little about this and I''m not sure if we did or not. If you look at the Cucumber support for Spork we used the same interface that RSpec had, but in the end we had to do some special handling of Cucumber-specific needs (the StepMother) to make it work. You would only need to have this special handling if you were doing something similar to Spork, and that handling can not be done on the client side. Given that custom code has to be written to have the two play nicely the question is where does this code belong. I think where it is currently, in Spork, is the correct place. Since that is really the responsibility of Spork (serving up forked test runs that is) I think it makes sense from a maintenance point of view to have Spork responsible for that. I''m still thinking it over though so if someone has a concrete idea of how to switch the dependency and what advantages it would bring I''m all ears. :) -Ben> > >> 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? >> > > That''s why I asked now, incase RSpec 3 changes it again and the circular dep bites once more ;) > > Cheers > Ash > > > * I''m not sure it''s an easy one to solve because you have to figure out when to read in spec.opts. > > ** Sorta like how gem subcommands (eg gemedit) work. I''d love to know how that mojo does its stuff :) > > >