-
Notifications
You must be signed in to change notification settings - Fork 142
Description
Your environment
ruby -v:3.1rdbg -v:1.6.1
Describe the bug
When running bundle exec, bundler will inject something like -r path_to_bundler/setup into the RUBYOPT environment variable. And that's how it makes sure every gem loaded afterward is at the version specified in the Gemfile.lock.
But currently, the rdbg executable aren't passing this info correctly.
Lines 16 to 21 in 390b764
| env = ::DEBUGGER__::Config.config_to_env_hash(config) | |
| rubyopt = env['RUBYOPT'] | |
| env['RUBY_DEBUG_ADDED_RUBYOPT'] = added = "-r #{libpath}/#{start_mode}" | |
| env['RUBYOPT'] = "#{added} #{rubyopt}" | |
| exec(env, cmd, *ARGV) |
This code has 2 problems:
rubyopt = env['RUBYOPT']should berubyopt = ENV['RUBYOPT']becauseenvis a hash produced with the debugger configurations instead of the current environment. So currently theenv['RUBYOPT']is alwaysnil."#{added} #{rubyopt}"should be#{rubyopt} "#{added}instead to honor the requiring order.-rbundler/setup -rdebug/startinstead of-rdebug/start -rbundler/setupbecause the later will cause the debugger not to load the dependency specified inGemfile.
To Reproduce
This problem doesn't always cause real issues though. Errors only happen when all these conditions are fulfilled:
- There's a library used by both the debugger and the user's program, e.g.
timeout(used byreline, which is used by the debugger) - The system has at least 2 versions of the gem (e.g.
0.2.0and0.3.0) - The user program uses the older version (e.g.
0.2.0)
Then rdbg -c -- <user program> will trigger this error:
You have already activated timeout 0.3.0, but your Gemfile requires timeout 0.2.0. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
The real program though, is that appending bundle exec before rdbg won't fix the problem as it should due to the described reason.
Expected behavior
bundle exec rdbg # ... should avoid the Gem::LoadError.