Using the "And debugger" step twice in a Cucumber scenario prints a wall of warnings

[codener]

The second (or any further) invocation of the debugger step print these warnings:

/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::UnrecognizedSwitch
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of UnrecognizedSwitch was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::NotImplementedError
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of NotImplementedError was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::CantReturnToNormalMode
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of CantReturnToNormalMode was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::IllegalParameter
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of IllegalParameter was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::IrbAlreadyDead
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of IrbAlreadyDead was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::IrbSwitchedToCurrentThread
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of IrbSwitchedToCurrentThread was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::NoSuchJob
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of NoSuchJob was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::CantShiftToMultiIrbMode
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of CantShiftToMultiIrbMode was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::CantChangeBinding
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of CantChangeBinding was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::UndefinedPromptMode
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of UndefinedPromptMode was here
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: already initialized constant IRB::IllegalRCGenerator
/home/me/.rbenv/versions/2.2.3/lib/ruby/2.2.0/e2mmap.rb:133: warning: previous definition of IllegalRCGenerator was here
>> (debugger prompt)

I assume this is caused by how IRB is required/initialized inside the step.

Expected behavior

No wall of warnings.

[judithroth]

I looked into this and found which part of the code causes the warnings when triggered more than once. I also found several ways in which this can be fixed but every one has its own drawbacks.

1. Swallow all warnings:

  Kernel.silence_warnings do
    IRB.setup(nil)
  end

I don't think its good to swallow all warnings because in future ruby versions there may be new warnings we want to know of so we can take action.

2.) Checking if IRB is already set up by checking if one of the constants the warnings complain about is already loaded:

  unless Object.const_defined?('IRB::UnrecognizedSwitch')
    IRB.setup(nil)
  end

This could be prone to errors because class names may differ between different versions of ruby and then its not working.

3.) Check if we ran the code before and if yes omit it:

  unless @irb_setup
    IRB.setup(nil)
    @irb_setup = true
  end

The only drawback here is that it only fixes the error if the step is called more than once in one scenario. If it is called in two or more different scenarios in the same run it will again lead to the wall of warnings. For me using debugger in multiple scenarios in the same run is an edge case - I usually only debug one scenario at a time and once this works I go on to the next one. Therefore this seems to be the best solution to me although it does not cover every way the warnings can be triggered.

Any opinions on this? Or maybe other ideas to solve this?

[codener]

Thanks for investigating and preparing solutions.

1. Should be okay because we're only silencing warnings.
2. My favorite. I would add a method irb_already_setup? that checks for some IRB constants deemed stable, and only do the IRB setup if it's not done yet.
3. While it might be true that noone puts a debugger into multiple scenarios, this one is too weak in my eyes.

The best solution would be to simply ask IRB whether it is setup, but a quick search brought no results on how to achieve this.

[foobear]

Voting for option 2 if we can find a better way to determine if it is already set up.

I agree with @judithroth that looking at the constant currently being defined twice is not that bullet-proof.

Can we maybe find something that is defined during setup? In IRB.conf, only :VERSION seems to be available before calling setup, so we could check if something like IRB.conf[:AT_EXIT] was defined. Not significantly better, but more fitting for "has this IRB been configured?".

Works for me ™ on versions 0.9.5 (April 2013) and 1.0.0 (December 2018).

[judithroth]

Fixed with Version 1.12.3

[codener]

Awesome, thanks!