I just published a quick article showing how to use the patch I provided and David just release in RSpec 1.2.7 to run your specs using multiruby: http://talklikeaduck.denhaven2.com/2009/06/24/rspec-meet-multiruby -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
On Wed, Jun 24, 2009 at 8:54 PM, Rick DeNatale<rick.denatale at gmail.com> wrote:> I just published a quick article showing how to use the patch I > provided and David just release in RSpec 1.2.7 to run your specs using > multiruby: > > http://talklikeaduck.denhaven2.com/2009/06/24/rspec-meet-multiruby >Tried to leave you this comment: I have setup ''mr'' as alias for multiruby, so I can do mr -S rake spec Which is going to produce the exact same results than your task (without inject system calls for which). Also, going with above example, this will work on Windows too, using Pik: pik run "rake spec" -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
On Wed, Jun 24, 2009 at 8:18 PM, Luis Lavena<luislavena at gmail.com> wrote:> On Wed, Jun 24, 2009 at 8:54 PM, Rick DeNatale<rick.denatale at gmail.com> wrote: >> I just published a quick article showing how to use the patch I >> provided and David just release in RSpec 1.2.7 to run your specs using >> multiruby: >> >> http://talklikeaduck.denhaven2.com/2009/06/24/rspec-meet-multiruby >> > > Tried to leave you this comment: > > I have setup ''mr'' as alias for multiruby, so I can do > > mr -S rake specAs far as I can tell, this requires that you install rake in all the various multiruby setups. But the real reason I went the way I did was that it allows other rake tasks to depend on the multiruby rspec tasks without requiring ALL rake tests to run under multiruby. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
On Wed, Jun 24, 2009 at 11:24 PM, Rick DeNatale<rick.denatale at gmail.com> wrote:> On Wed, Jun 24, 2009 at 8:18 PM, Luis Lavena<luislavena at gmail.com> wrote: >> On Wed, Jun 24, 2009 at 8:54 PM, Rick DeNatale<rick.denatale at gmail.com> wrote: >>> I just published a quick article showing how to use the patch I >>> provided and David just release in RSpec 1.2.7 to run your specs using >>> multiruby: >>> >>> http://talklikeaduck.denhaven2.com/2009/06/24/rspec-meet-multiruby >>> >> >> Tried to leave you this comment: >> >> I have setup ''mr'' as alias for multiruby, so I can do >> >> mr -S rake spec > > As far as I can tell, this requires that you install rake in all the > various multiruby setups. >Yes, but that should be true for environment isolation since different versions of ruby behave in different ways, add to the mix the Gems and you have a Molotov coctail on your hands ;-) But you can use multiruby_setup rubygems:merge Which should symlink the rubygems installations of your different ruby versions and get those shared. (beware of gems with native extensions and having ruby 1.8 and 1.9 with multiruby).> But the real reason I went the way I did was that it allows other rake > tasks to depend on the multiruby rspec tasks without requiring ALL > rake tests to run under multiruby.But that is kind of cheating. Let say I have only 1.9 on my system, I checkout a project and try to get the list of task of that project with rake -T Now, since I was not testing 100% against Ruby 1.9, I never found that one of the gems I depend on (let''s say Hoe) was not 1.9 compatible. Then I get people complaining about my project not working with Ruby 1.9... but "it worked on my computer" you would say. Anyhow, different approaches I believe, and in any case, is good to know that RSpec now supports setting the ruby interpreter and not leveraging on RUBY definition itself. Thank you for the patch. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
On Thu, Jun 25, 2009 at 12:15 AM, Luis Lavena<luislavena at gmail.com> wrote:> On Wed, Jun 24, 2009 at 11:24 PM, Rick DeNatale<rick.denatale at gmail.com> wrote: >> On Wed, Jun 24, 2009 at 8:18 PM, Luis Lavena<luislavena at gmail.com> wrote: >>> On Wed, Jun 24, 2009 at 8:54 PM, Rick DeNatale<rick.denatale at gmail.com> wrote:>> But the real reason I went the way I did was that it allows other rake >> tasks to depend on the multiruby rspec tasks without requiring ALL >> rake tests to run under multiruby. > > But that is kind of cheating. > > Let say I have only 1.9 on my system, I checkout a project and try to > get the list of task of that project with rake -T > > Now, since I was not testing 100% against Ruby 1.9, I never found that > one of the gems I depend on (let''s say Hoe) was not 1.9 compatible.I think that hoe is a good example of when 1.9 compatibility is optional. Hoe is only used to deploy the gem to rubyforge... It doesn''t affect the compatibility of the gem being released. And the rake tasks I''m thinking of are things like having a deploy/publish task which pre-regs running the specs for the thing being deployed and making sure they run under multiruby as a pre-req to deployment/publication. I this case you want to be able to run only the specs under multiruby, not the whole deployment/publication task, which would (try) to deploy/publish 2/3/4 times depending on how many ruby installations you have set up for multiruby. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale