Debugging Bundler can be challenging, don’t be discouraged 🤗.
Make sure you’ve followed the development setup docs before trying to debug.
The easiest way to debug is to print debug. Put puts statements anywhere in the code that you want to see an object or variable and you’ll see your puts in the console output.
This can be especially helpful when running tests.
puts "stacktrace: #{caller_locations(0).join("\n")}"
puts "@definition: #{@definition}"
puts "specification.class.name: #{specification.class.name}"
puts "spec.method(:to_checksum).source_location: #{spec.method(:to_checksum).source_location}"
# etc
To learn more print debugging strategies, [TODO: link to doc]
REPL (or Read-Eval-Print Loop) is a way to interact with your code.
With REPL you can look at the values of objects and variables, the stack trace, where methods are defined etc.
To use REPL, place a binding.irb wherever you’d like to take a look around. An interactive irb console will open when your code gets to your breakpoint.
To learn more about using IRB, [TODO: link to doc]
Interactive debugging is like REPL + the ability to advance the code execution line by line.
When testing Bundler locally, you can use any debugger that you are comfortable with for interactive debugging.
debug and pry-byebug are common favorites. debug has been included with Ruby since v3.1.
You just need your chosen debugger gem installed globally. Then you will need to require it on the command line before running your local Bundler.
RUBYOPT=-rdebug dbundle # for the debug gem
RUBYOPT=-rpry-byebug dbundle # for pry-byebug
Note Interactive debugging is not possible in the test suite. Most tests use Open3 to run Bundler in a sub process and capture the output into a string, which makes it impossible to use pry even if you can get it to load.
The easiest way to test locally is to set up a directory with a Gemfile and run your Bundler shell alias (see the development setup docs for instructions on setting up the alias).
We recommend putting this directory inside of tmp so that your local tests don’t accidentally get committed.
cd tmp
mkdir [name of directory for local testing] && cd [name of directory for local testing]
dbundle init
And then you should have a Gemfile ready for you to edit as needed for your testing.
pryTo dive into the code with Pry: RUBYOPT=-rpry dbundle to require pry and then run commands.
For background context: you can manipulate environment variables in Ruby to control the Ruby interpreter’s behavior. Ruby uses the RUBYOPT environment variable to specify options to launch Ruby with.
The arguments of RUBYOPT are applied as if you had typed them as flags after ruby. The -r flag means ‘require’. So saying -rpry means require 'pry'. To illustrate, ruby -rpry /path/to/bundle is the same as RUBYOPT=-rpry ruby /path/to/bundle.
So, RUBYOPT=-rpry dbundle is saying “require pry and require this path to Bundler”, which means that you will start your development environment with pry and your local bundler.
Why is this necessary? Why isn’t require 'pry'; binding.pry enough?
The reason for combining RUBYOPT with dbundle is because Bundler takes over what gems are available. If you have pry installed on your machine but not included in the Gemfile, Bundler itself will remove pry from the list of gems you can require. Setting RUBYOPT=-rpry is a way to require pry before Bundler takes over and removes it from the list of gems that can be required. That way, later, you can take advantage of binding.pry and have it work.
Unfortunately, if you waited until the point of binding.pry to require 'pry', it would fail anytime pry is not in the Gemfile.
By default, the initialized Gemfile’s remote is "https://rubygems.org". You can add any gem hosted on rubygems and then run your Bundler shell alias (dbundle) to test your code.
# frozen_string_literal: true
source "https://rubygems.org"
gem 'tiny_css'
Put a breakpoint anywhere you want the debugger to pause (binding.break for debug or binding.pry for pry-byebug). Run your Bundler shell alias.
RUBYOPT=-rdebug dbundle
And your breakpoint will display, paused, in your console.
If you have a very specific scenario you want to test (maybe an example that failed while running the test suite), the easiest way is to use the tmp gems from a previous test suite run.
Run the test suite in parallel if you haven’t already.
bin/parallel_rspec
Then you’ll find built gems in the bundler/tmp directory, e.g. bundler/tmp/1/gems/remote1/
You can set up your Gemfile with a file source pointing to the built gems from your test run.
# frozen_string_literal: true
source "file:///[path to repo's bundler directory]/tmp/1/gems/remote1/"
gem "rack", '=0.9.1'
Then you can test in the same way as you did in the previous example when fetching the gem from the RubyGems source.