Configuration is out of scope

[ghost]

Reproduction:

1. Use capybara-screenshot on latest version (1.0.12) i.e. in some cucumber/capybara/capybara-webkit oriented project
2. Run some basic RSpet expect statement with fail/negative result that triggers screenshot/html saving file i.e. expect(1).to eq(2)

Actual result:
wrong number of arguments (0 for 1) (ArgumentError)

Note: wrong configuration method is used. Should be in RSpec scope, but it is read from Ruby context:

"/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/mkmf.rb:1856:in `configuration'"

"/.rvm/gems/ruby-2.2.4/gems/rspec-expectations-3.4.0/lib/rspec/expectations/configuration.rb:66:in `color?'"

"/.rvm/gems/ruby-2.2.4/gems/rspec-expectations-3.4.0/lib/rspec/expectations/fail_with.rb:8:in `differ'",

[mattheworiordan]

Can you confirm if this happens in an older version of RSpec to help isolate whether this is a new issue introduced by a changein RSpec?

[ghost]

Hard to say, RSpec is already required, anyway while I`m using project with such Gemfile.lock:
PATH
specs:
cuculungwa (0.0.87)
aruba (> 0.8, >= 0.8.1)
capybara (> 2.4, >= 2.4.4)
capybara-screenshot (> 1.0, >= 1.0.11)
capybara-webkit (> 1.6, >= 1.6.0)
cucumber (> 2.0, >= 2.0.2)
headless (> 2.1, >= 2.1.0)
i18n (> 0.7, >= 0.7.0)
json (> 1.8, >= 1.8.3)
poltergeist (> 1.6, >= 1.6.0)
selenium-webdriver (> 2.46, >= 2.46.2)
site_prism (~> 2.7, >= 2.7)

GEM
remote: http://rubygems.org/
specs:
addressable (2.4.0)
aruba (0.14.1)
childprocess (> 0.5.6)
contracts (> 0.9)
cucumber (>= 1.3.19)
ffi (> 1.9.10)
rspec-expectations (>= 2.99)
thor (> 0.19)
builder (3.2.2)
capybara (2.7.0)
addressable
mime-types (>= 1.16)
nokogiri (>= 1.3.3)
rack (>= 1.0.0)
rack-test (>= 0.5.4)
xpath (> 2.0)
capybara-screenshot (1.0.12)
capybara (>= 1.0, < 3)
launchy
capybara-webkit (1.11.0)
capybara (>= 2.3.0, < 2.8.0)
json
childprocess (0.5.9)
ffi (> 1.0, >= 1.0.11)
cliver (0.3.2)
contracts (0.14.0)
cucumber (2.3.3)
builder (>= 2.1.2)
cucumber-core (> 1.4.0)
cucumber-wire (> 0.0.1)
diff-lcs (>= 1.1.3)
gherkin (> 3.2.0)
multi_json (>= 1.7.5, < 2.0)
multi_test (>= 0.1.2)
cucumber-core (1.4.0)
gherkin (> 3.2.0)
cucumber-wire (0.0.1)
diff-lcs (1.2.5)
faraday (0.9.2)
multipart-post (>= 1.2, < 3)
ffi (1.9.10)
ffi (1.9.10-x86-mingw32)
gherkin (3.2.0)
headless (2.2.3)
i18n (0.7.0)
json (1.8.3)
launchy (2.4.3)
addressable (> 2.3)
mime-types (3.0)
mime-types-data (> 3.2015)
mime-types-data (3.2016.0221)
mini_portile2 (2.0.0)
multi_json (1.11.3)
multi_test (0.1.2)
multipart-post (2.0.0)
nokogiri (1.6.7.2)
mini_portile2 (> 2.0.0.rc2)
nokogiri (1.6.7.2-x86-mingw32)
mini_portile2 (> 2.0.0.rc2)
poltergeist (1.9.0)
capybara (> 2.1)
cliver (> 0.3.1)
multi_json (> 1.0)
websocket-driver (>= 0.2.0)
rack (1.6.4)
rack-test (0.6.3)
rack (>= 1.0)
rdoc (4.2.2)
json (> 1.4)
rspec-expectations (3.4.0)
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (> 3.4.0)
rspec-support (3.4.1)
rubyzip (1.2.0)
sdoc (0.4.1)
json (> 1.7, >= 1.7.7)
rdoc (> 4.0)
selenium-webdriver (2.53.0)
childprocess (> 0.5)
rubyzip (> 1.0)
websocket (> 1.0)
site_prism (2.9)
addressable (>= 2.3.3, < 3.0)
capybara (>= 2.1, < 3.0)
thor (0.19.1)
websocket (1.2.3)
websocket-driver (0.6.3)
websocket-extensions (>= 0.1.0)
websocket-extensions (0.1.2)
xpath (2.0.0)
nokogiri (~> 1.3)

It fails, while only capybara-screenshot is downgraded to 1.0.11(~> 1.0, <= 1.0.11) it`s just fine:

PATH
remote: /home/kaftee/w3/cuculungwa-core
specs:
cuculungwa (0.0.87)
aruba (> 0.8, >= 0.8.1)
capybara (> 2.4, >= 2.4.4)
capybara-screenshot (> 1.0, <= 1.0.11)
capybara-webkit (> 1.6, >= 1.6.0)
cucumber (> 2.0, >= 2.0.2)
headless (> 2.1, >= 2.1.0)
i18n (> 0.7, >= 0.7.0)
json (> 1.8, >= 1.8.3)
poltergeist (> 1.6, >= 1.6.0)
selenium-webdriver (> 2.46, >= 2.46.2)
site_prism (~> 2.7, >= 2.7)

GEM
remote: http://rubygems.org/
specs:
addressable (2.4.0)
aruba (0.14.1)
childprocess (> 0.5.6)
contracts (> 0.9)
cucumber (>= 1.3.19)
ffi (> 1.9.10)
rspec-expectations (>= 2.99)
thor (> 0.19)
builder (3.2.2)
capybara (2.7.0)
addressable
mime-types (>= 1.16)
nokogiri (>= 1.3.3)
rack (>= 1.0.0)
rack-test (>= 0.5.4)
xpath (> 2.0)
capybara-screenshot (1.0.11)
capybara (>= 1.0, < 3)
launchy
capybara-webkit (1.11.0)
capybara (>= 2.3.0, < 2.8.0)
json
childprocess (0.5.9)
ffi (> 1.0, >= 1.0.11)
cliver (0.3.2)
contracts (0.14.0)
cucumber (2.3.3)
builder (>= 2.1.2)
cucumber-core (> 1.4.0)
cucumber-wire (> 0.0.1)
diff-lcs (>= 1.1.3)
gherkin (> 3.2.0)
multi_json (>= 1.7.5, < 2.0)
multi_test (>= 0.1.2)
cucumber-core (1.4.0)
gherkin (> 3.2.0)
cucumber-wire (0.0.1)
diff-lcs (1.2.5)
faraday (0.9.2)
multipart-post (>= 1.2, < 3)
ffi (1.9.10)
ffi (1.9.10-x86-mingw32)
gherkin (3.2.0)
headless (2.2.3)
i18n (0.7.0)
json (1.8.3)
launchy (2.4.3)
addressable (> 2.3)
mime-types (3.0)
mime-types-data (> 3.2015)
mime-types-data (3.2016.0221)
mini_portile2 (2.0.0)
multi_json (1.11.3)
multi_test (0.1.2)
multipart-post (2.0.0)
nokogiri (1.6.7.2)
mini_portile2 (> 2.0.0.rc2)
nokogiri (1.6.7.2-x86-mingw32)
mini_portile2 (> 2.0.0.rc2)
poltergeist (1.9.0)
capybara (> 2.1)
cliver (> 0.3.1)
multi_json (> 1.0)
websocket-driver (>= 0.2.0)
rack (1.6.4)
rack-test (0.6.3)
rack (>= 1.0)
rdoc (4.2.2)
json (> 1.4)
rspec-expectations (3.4.0)
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (> 3.4.0)
rspec-support (3.4.1)
rubyzip (1.2.0)
sdoc (0.4.1)
json (> 1.7, >= 1.7.7)
rdoc (> 4.0)
selenium-webdriver (2.53.0)
childprocess (> 0.5)
rubyzip (> 1.0)
websocket (> 1.0)
site_prism (2.9)
addressable (>= 2.3.3, < 3.0)
capybara (>= 2.1, < 3.0)
thor (0.19.1)
websocket (1.2.3)
websocket-driver (0.6.3)
websocket-extensions (>= 0.1.0)
websocket-extensions (0.1.2)
xpath (2.0.0)
nokogiri (~> 1.3)

[tpbowden]

I'm also having the same issue using RSpec 3.4.4, Cucumber 2.3.3 and Ruby 2.3.0

[fschwahn]

I've had the same problem, I tried with rspec 3.1.x, as well as rspec 3.5.0.beta3 - the problem was fixed by downgrading to capybara-screenshot 1.0.11. So it seems the problem was introduced in the last update.

[ddsferreira]

This bug can be replicated the following way:

$ irb
> RUBY_VERSION
=> '2.3.0'
> require 'yaml'
> YAML.public_method_defined?(:configuration)
=> false
> YAML.respond_to?(:configuration)
=> false
> require 'mkmf'
> YAML.public_method_defined?(:configuration)
=> false
> YAML.respond_to?(:configuration)
=> true

Object.constants do |constant|
  constant.respond_to?(:configuration) ==> true
end

What happens is that there is a bug in: require 'mkmf'
Here it is the bug issue: mkmf bug

Also there is a different behaviour for core classes over library or gem classes and/or modules under Object namespace.

I'm using capybara with rspec expectations and
This makes rspec expectations brake when color options is set.

If you like I can give you more details about it.

[ddsferreira]

For the time being my advise would be to try to remove require 'mkmf' from the code base like suggested by Nobu in the Ruby Lang issue opened.

[fschwahn]

The require statement was added in commit 29d6f1b to get access to find_exectuable - however a later commit moved to a different method for finding the executable, so the require 'mkmf' is simply a leftover. It can just be removed and this issue is fixed.

[ddsferreira]

Great 👍

[mattheworiordan]

Hi. I believe 012208c fixes this issue. Please reopen if not the case.

Thanks @fschwahn for looking into this.