NameError in rspec-core-2.14.1/lib/rspec/core/reporter.rb

[znz]

rspec-core-2.14.1 does not work with ci_reporter-1.9.0.

% bundle exec rake -f $(bundle show ci_reporter)/stub.rake ci:setup:rspec default
rm -rf spec/reports
/Users/kazu/.rbenv/versions/1.9.3-p429/bin/ruby -S rspec
/private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:134:in `method': undefined method `start' for class `CI::Reporter::RSpec' (NameError)
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:134:in `understands'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:24:in `block in register_listener'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:23:in `each'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:23:in `register_listener'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:10:in `block in initialize'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:9:in `each'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/reporter.rb:9:in `initialize'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/configuration.rb:591:in `new'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/configuration.rb:591:in `reporter'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/world.rb:62:in `reporter'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/world.rb:88:in `announce_filters'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/command_line.rb:23:in `run'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/runner.rb:80:in `run'
    from /private/tmp/foo/vendor/bundle/ruby/1.9.1/gems/rspec-core-2.14.1/lib/rspec/core/runner.rb:17:in `block in autorun'
/Users/kazu/.rbenv/versions/1.9.3-p429/bin/ruby -S rspec failed
% cat Gemfile      
source 'https://rubygems.org'
gem 'rails', '3.2.13'
gem 'sqlite3'
group :development, :test do
  gem 'rspec-rails'
end
gem 'ci_reporter', require: false, group: :test
% bundle list
Gems included by the bundle:
  * actionmailer (3.2.13)
  * actionpack (3.2.13)
  * activemodel (3.2.13)
  * activerecord (3.2.13)
  * activeresource (3.2.13)
  * activesupport (3.2.13)
  * arel (3.0.2)
  * builder (3.0.4)
  * bundler (1.3.5)
  * ci_reporter (1.9.0)
  * diff-lcs (1.2.4)
  * erubis (2.7.0)
  * hike (1.2.3)
  * i18n (0.6.1)
  * journey (1.0.4)
  * json (1.8.0)
  * mail (2.5.4)
  * mime-types (1.23)
  * multi_json (1.7.7)
  * polyglot (0.3.3)
  * rack (1.4.5)
  * rack-cache (1.2)
  * rack-ssl (1.3.3)
  * rack-test (0.6.2)
  * rails (3.2.13)
  * railties (3.2.13)
  * rake (10.1.0)
  * rdoc (3.12.2)
  * rspec-core (2.14.1)
  * rspec-expectations (2.14.0)
  * rspec-mocks (2.14.1)
  * rspec-rails (2.14.0)
  * sprockets (2.2.2)
  * sqlite3 (1.3.7)
  * thor (0.18.1)
  * tilt (1.4.1)
  * treetop (1.4.14)
  * tzinfo (0.3.37)

[alindeman]

ci_reporter uses method_missing to delegate calls to another formatter. Unfortunately the changes in #967 don't expect that (respond_to? is true, but method fails because the method is not actually on the object itself, but on the @formatter ci_reporter delegates to)

I think @JonRowe's original fix of implementing #start on DeprecationFormatter (as a no-op) might fix the original issue in a better way (even if it's still a hack of sorts) ... especially if we're planning to nuke some of this code from orbit in 3.x.

What do you think? @myronmarston @JonRowe

[JonRowe]

I think @myronmarston is right that the behaviour belongs in Reporter (otherwise I wouldn't have refactored #967) but that using method to check owner is a hack to accomplish the change in behaviour required (although a NoMethodError was completely unexpected behaviour). I'd like to revert to the trivial implement #start on DeprecationFormatter as it will have 0 side effects, and continue with the planned refactor for 3.

[alindeman]

I think @myronmarston is right that the behaviour belongs in Reporter (otherwise I wouldn't have refactored #967) but that using method to check owner is a hack to accomplish the change in behaviour required (although a NoMethodError was completely unexpected behaviour). I'd like to revert to the trivial implement #start on DeprecationFormatter as it will have 0 side effects, and continue with the planned refactor for 3.

👍 for this and a 2.14.2 release.

[myronmarston]

Honestly, it seems like a bug for an object to respond_to? a message but raise a NoMethodError when something calls method to get the method. This is precisely why 1.9 provides respond_to_missing?.

That said, we broke this and I agree with changing back to Jon's simpler fix.

[alindeman]

Honestly, it seems like a bug for an object to respond_to? a message but raise a NoMethodError when something calls method to get the method. This is precisely why 1.9 provides respond_to_missing?.

I don't necessarily agree. I think objects should be free to deal with messages however they like, and sometimes that's not with a pre-defined method of the same name.

In languages where methods are really just functions hanging off an object (JavaScript, Python), I might agree.

But in Ruby, I think trying to find out what code would be executed when sending a message without actually sending a message is fragile ... and we should avoid it unless absolutely necessary.

[JonRowe]

Merged #970, so this is fixed in 2-14-maintenance, When do we want to cut another release?

[myronmarston]

I just did :).

[JonRowe]

❤️ fixed in 2.14.2

[myronmarston]

BTW, can you merge your fixes into 2.99? I've already taken care of the changelog in all branches.

[JonRowe]

Was just about to do that :)

[snowblink]

Thanks for the fix. Could someone also update the rspec meta package?

[myronmarston]

There's no need to (and we don't ever bother with patch releases). A fresh gem or bundle install of rspec 2.14.0 will pull in the latest 2.14.x releases of the dependent gems. A bundle update will do the same.

Sent from my iPhone

On Jul 10, 2013, at 2:06 AM, Jonathan Lim notifications@github.com wrote:

Thanks for the fix. Could someone also update the rspec meta package?

—
Reply to this email directly or view it on GitHub.