You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
rubyopt = env['RUBYOPT'] should be rubyopt = ENV['RUBYOPT'] because env is a hash produced with the debugger configurations instead of the current environment. So currently the env['RUBYOPT'] is always nil.
"#{added} #{rubyopt}" should be #{rubyopt} "#{added} instead to honor the requiring order.
-rbundler/setup -rdebug/start instead of -rdebug/start -rbundler/setup because the later will cause the debugger not to load the dependency specified in Gemfile.
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 by reline, which is used by the debugger)
The system has at least 2 versions of the gem (e.g. 0.2.0 and 0.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.
The text was updated successfully, but these errors were encountered:
st0012
added a commit
to st0012/debug
that referenced
this issue
Jul 13, 2022
Your environment
ruby -v
:3.1
rdbg -v
:1.6.1
Describe the bug
When running
bundle exec
, bundler will inject something like-r path_to_bundler/setup
into theRUBYOPT
environment variable. And that's how it makes sure every gem loaded afterward is at the version specified in theGemfile.lock
.But currently, the
rdbg
executable aren't passing this info correctly.debug/exe/rdbg
Lines 16 to 21 in 390b764
This code has 2 problems:
rubyopt = env['RUBYOPT']
should berubyopt = ENV['RUBYOPT']
becauseenv
is 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/start
instead of-rdebug/start -rbundler/setup
because 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:
timeout
(used byreline
, which is used by the debugger)0.2.0
and0.3.0
)0.2.0
)Then
rdbg -c -- <user program>
will trigger this error:The real program though, is that appending
bundle exec
beforerdbg
won't fix the problem as it should due to the described reason.Expected behavior
bundle exec rdbg # ...
should avoid theGem::LoadError
.The text was updated successfully, but these errors were encountered: