Hi there.
My understanding (which is limited) is that rspec uses at_exit to run its
specs. I don''t really know why - could somoene explain?
My problem with this behaviour is that I would like the running of a spec to
start an instance of solr (using Sunspot) if one is not running. The problem
with this is that Sunspot forks to start solr, and when these forks exit
they run my specs. At best this causes specs to be run more than once, at
worst it causes specs to fail in their hundreds.
I can fix this by adding an at_exit for each fork ...
fork do
...
at_exit { exit! }
end
but this means changing the Sunspot code, which I really shouldn''t have
to
do to run specs. So is their anything else I can do. Ideally in spec_helper
or another rspec support file.
TIA
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100707/21fa0378/attachment.html>
On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote:> Hi there. > > My understanding (which is limited) is that rspec uses at_exit to run its specs. I don''t really know why - could somoene explain?The initial motivation was that it makes it easy to make sure it works whether you run it with the ruby command or the rspec command. Over the years it has caused some trouble though, so I''d be interested in a different solution.> My problem with this behaviour is that I would like the running of a spec to start an instance of solr (using Sunspot) if one is not running. The problem with this is that Sunspot forks to start solr, and when these forks exit they run my specs. At best this causes specs to be run more than once, at worst it causes specs to fail in their hundreds. > > I can fix this by adding an at_exit for each fork ... > > fork do > ... > at_exit { exit! } > end > > but this means changing the Sunspot code, which I really shouldn''t have to do to run specs. So is their anything else I can do. Ideally in spec_helper or another rspec support file.I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve a similar problem. No guarantees it will stay there if I come up with a better way to deal with supporting multiple entry points, but if I remove it I''ll formally deprecate it (so you''re safe to use it). HTH, David> > TIA > > Andrew > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 8 July 2010 01:01, David Chelimsky <dchelimsky at gmail.com> wrote:> On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote: > > > Hi there. > > > > My understanding (which is limited) is that rspec uses at_exit to run its > specs. I don''t really know why - could somoene explain? > > The initial motivation was that it makes it easy to make sure it works > whether you run it with the ruby command or the rspec command. Over the > years it has caused some trouble though, so I''d be interested in a different > solution. > > > My problem with this behaviour is that I would like the running of a spec > to start an instance of solr (using Sunspot) if one is not running. The > problem with this is that Sunspot forks to start solr, and when these forks > exit they run my specs. At best this causes specs to be run more than once, > at worst it causes specs to fail in their hundreds. > > > > I can fix this by adding an at_exit for each fork ... > > > > fork do > > ... > > at_exit { exit! } > > end > > > > but this means changing the Sunspot code, which I really shouldn''t have > to do to run specs. So is their anything else I can do. Ideally in > spec_helper or another rspec support file. > > I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve a > similar problem. No guarantees it will stay there if I come up with a better > way to deal with supporting multiple entry points, but if I remove it I''ll > formally deprecate it (so you''re safe to use it). > > HTH, > David > > Thanks for your reply David. Does this only apply only to rspec2? (the beta16 seems a bit of a giveaway). Is there something I can do with rspec 1x. I''ve tried commenting out require ''spec/autorun'', but that had no effect. Is there is something I could do like put a monkey patch in spec helper. On a related note, can rspec 2 be used on rails 2x projects All best Andrew> > > TIA > > > > Andrew > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100708/d2b88c22/attachment-0001.html>
On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote:> On 8 July 2010 01:01, David Chelimsky <dchelimsky at gmail.com> wrote: > On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote: > > > Hi there. > > > > My understanding (which is limited) is that rspec uses at_exit to run its specs. I don''t really know why - could somoene explain? > > The initial motivation was that it makes it easy to make sure it works whether you run it with the ruby command or the rspec command. Over the years it has caused some trouble though, so I''d be interested in a different solution. > > > My problem with this behaviour is that I would like the running of a spec to start an instance of solr (using Sunspot) if one is not running. The problem with this is that Sunspot forks to start solr, and when these forks exit they run my specs. At best this causes specs to be run more than once, at worst it causes specs to fail in their hundreds. > > > > I can fix this by adding an at_exit for each fork ... > > > > fork do > > ... > > at_exit { exit! } > > end > > > > but this means changing the Sunspot code, which I really shouldn''t have to do to run specs. So is their anything else I can do. Ideally in spec_helper or another rspec support file. > > I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve a similar problem. No guarantees it will stay there if I come up with a better way to deal with supporting multiple entry points, but if I remove it I''ll formally deprecate it (so you''re safe to use it). > > HTH, > David > > Thanks for your reply David. Does this only apply only to rspec2?Yes.> (the beta 16 seems a bit of a giveaway). Is there something I can do with rspec 1x.Not sure, but I really don''t have time to experiment with this right now - sorry. If you do, and come up with something, please post it back and I''ll look at merging it.> I''ve tried commenting out require ''spec/autorun'', but that had no effect. Is there is something I could do like put a monkey patch in spec helper. > > On a related note, can rspec 2 be used on rails 2x projectsNot quite yet. Definitely in the plan, but probably not going to happen until the fall unless someone other than me makes it so. There is http://github.com/rsanheim/rspec-rails23, which works with a subset of rspec-rails-2 functionality and only up to beta.8. This is likely NOT to be the basis for an official rspec2-rails2 gem so please don''t use this expecting a smooth upgrade path once such a gem exists. HTH, David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100708/b7d46460/attachment.html>
On 8 July 2010 11:46, David Chelimsky <dchelimsky at gmail.com> wrote:> On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote: > > On 8 July 2010 01:01, David Chelimsky <dchelimsky at gmail.com> wrote: > >> On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote: >> >> > Hi there. >> > >> > My understanding (which is limited) is that rspec uses at_exit to run >> its specs. I don''t really know why - could somoene explain? >> >> The initial motivation was that it makes it easy to make sure it works >> whether you run it with the ruby command or the rspec command. Over the >> years it has caused some trouble though, so I''d be interested in a different >> solution. >> >> > My problem with this behaviour is that I would like the running of a >> spec to start an instance of solr (using Sunspot) if one is not running. The >> problem with this is that Sunspot forks to start solr, and when these forks >> exit they run my specs. At best this causes specs to be run more than once, >> at worst it causes specs to fail in their hundreds. >> > >> > I can fix this by adding an at_exit for each fork ... >> > >> > fork do >> > ... >> > at_exit { exit! } >> > end >> > >> > but this means changing the Sunspot code, which I really shouldn''t have >> to do to run specs. So is their anything else I can do. Ideally in >> spec_helper or another rspec support file. >> >> I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve >> a similar problem. No guarantees it will stay there if I come up with a >> better way to deal with supporting multiple entry points, but if I remove it >> I''ll formally deprecate it (so you''re safe to use it). >> >> HTH, >> David >> >> Thanks for your reply David. Does this only apply only to rspec2? > > > Yes. > > (the beta 16 seems a bit of a giveaway). Is there something I can do with > rspec 1x. > > > Not sure, but I really don''t have time to experiment with this right now - > sorry. If you do, and come up with something, please post it back and I''ll > look at merging it. > > I''ve tried commenting out require ''spec/autorun'', but that had no effect. > Is there is something I could do like put a monkey patch in spec helper. > > On a related note, can rspec 2 be used on rails 2x projects > > > Not quite yet. Definitely in the plan, but probably not going to happen > until the fall unless someone other than me makes it so. > > There is http://github.com/rsanheim/rspec-rails23, which works with a > subset of rspec-rails-2 functionality and only up to beta.8. This is likely > NOT to be the basis for an official rspec2-rails2 gem so please don''t use > this expecting a smooth upgrade path once such a gem exists. > > HTH, > David > >Thanks for your input David, current fix is to monkey patch the offending code and add at_exit { exit! } to the end of each fork block. Not pretty, but it will do for now. Clearly we will have to bite the bullet and go to rails3 rspec2 at some point, struggling to keep up with the pace of change at the moment. All best Andrew> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100708/7ef2d831/attachment.html>
Andrew, On Thu, Jul 8, 2010 at 7:47 AM, Andrew Premdas <apremdas at gmail.com> wrote:> > > On 8 July 2010 11:46, David Chelimsky <dchelimsky at gmail.com> wrote: >> >> On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote: >> >> On 8 July 2010 01:01, David Chelimsky <dchelimsky at gmail.com> wrote: >>> >>> On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote: >>> >>> > Hi there. >>> > >>> > My understanding (which is limited) is that rspec uses at_exit to run >>> > its specs. I don''t really know why - could somoene explain? >>> >>> The initial motivation was that it makes it easy to make sure it works >>> whether you run it with the ruby command or the rspec command. Over the >>> years it has caused some trouble though, so I''d be interested in a different >>> solution. >>> >>> > My problem with this behaviour is that I would like the running of a >>> > spec to start an instance of solr (using Sunspot) if one is not running. The >>> > problem with this is that Sunspot forks to start solr, and when these forks >>> > exit they run my specs. At best this causes specs to be run more than once, >>> > at worst it causes specs to fail in their hundreds. >>> > >>> > I can fix this by adding an at_exit for each fork ... >>> > >>> > ? ? fork do >>> > ? ? ? ... >>> > ? ? ? at_exit { exit! } >>> > ? ? end >>> > >>> > but this means changing the Sunspot code, which I really shouldn''t have >>> > to do to run specs. So is their anything else I can do. Ideally in >>> > spec_helper or another rspec support file. >>> >>> I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve >>> a similar problem. No guarantees it will stay there if I come up with a >>> better way to deal with supporting multiple entry points, but if I remove it >>> I''ll formally deprecate it (so you''re safe to use it). >>> >>> HTH, >>> David >>> >> Thanks for your reply David. Does this only apply only to rspec2? >> >> Yes. >> >> (the beta 16 seems a bit of a giveaway). Is there something I can do with >> rspec 1x. >> >> Not sure, but I really don''t have time to experiment with this right now - >> sorry. If you do, and come up with something, please post it back and I''ll >> look at merging it. >> >> I''ve tried commenting out ?require ''spec/autorun'', but that had no effect. >> Is there is something I could do like put a monkey patch in spec helper. >> On a related note, can rspec 2 be used on rails 2x projects >> >> Not quite yet. Definitely in the plan, but probably not going to happen >> until the fall unless someone other than me makes it so. >> There is?http://github.com/rsanheim/rspec-rails23, which works with a >> subset of rspec-rails-2 functionality and only up to beta.8. This is likely >> NOT to be the basis for an official rspec2-rails2 gem so please don''t use >> this expecting a smooth upgrade path once such a gem exists. >> HTH, >> David > > Thanks for your input David, current fix is to monkey patch the offending > code and add ?at_exit { exit! } to the end of each fork block. Not pretty, > but it will do for now. Clearly we will have to bite the bullet and go to > rails3 rspec2 at some point, struggling to keep up with the pace of change > at the moment.While I came up with my own solution to this problem, I would love to compare solutions. Here''s what I came up with: http://gist.github.com/511874 Best regards, Michael Guterl