RubyMine 6.0.2 with "debugger" gem without modifying Gemfile.lock?

Question

I am using RubyMine (v6.0.2), but my teammates are not, so they need the "debugger" gem in the gemfile. I can conditionally un-require the Gemfile when running RubyMine (so the Gemfile can be shared and identical), but since the 'debugger' gem is not included, the Gemfile.lock file changes depending on whether the project was last run with RubyMine or not. This creates a lot of noise in redundant Gemfile.lock changes.

I've tried using 'debugger-xml' gem; that doesn't solve the issue.

So -- how can I run RubyMine 6.0.2, with the 'debugger' gem in the Gemfile, without having Gemfile.lock change?

Answer 1

I've been working on this issue from the other side of the table. I use the debugger gem, but have team mates that use RubyMine.

We discussed several potential solutions but they all involved conditional checks in the Gemfile that would result in a modified Gemfile.lock.

I googled around for a better solution and found this SO post: How to use gems not in a Gemfile when working with bundler?

Combining a few of the answers in there, I came up with this solution:

1. Remove the debugger gem from the Gemfile.
2. Create a Gemfile.local with the contents below.
3. Add Gemfile.local to the .gitignore file if using git.
4. Create a function and shell alias.
5. Start rails with $ be rails s

How it all works!

Bundler will use the file named Gemfile by default, but this behavior can be overridden by specifying a BUNDLE_GEMFILE environment variable. Bundler will use/create the lock file with the same name as the BUNDLE_GEMFILE.

The shell function __bundle_exec_custom will check to see if there is a Gemfile.local file in the CWD. If there is, then the BUNDLE_GEMFILE variable is set and used. Otherwise, the default Gemfile is used.

This will allow a developer to use any gems that they want for local development without having to impact the application as a whole.

Gemfile.local:

source "https://rubygems.org"

gemfile = File.join(File.dirname(__FILE__), 'Gemfile')
if File.readable?(gemfile)
  puts "Loading #{gemfile}..." if $DEBUG
  instance_eval(File.read(gemfile))
end

gem 'debugger'

Function and shell alias:

__bundle_exec_custom () {
  if [ -f Gemfile.local ]
  then
    BUNDLE_GEMFILE="Gemfile.local" bundle exec $@
  else
    bundle exec $@
  fi
}

# Rails aliases
alias be='__bundle_exec_custom'

Answer 2

I think I found it. Apparently, RubyMine does not deal well with the debugger gem being required into the Rails app, but has no issue with the gem just being installed.

The solution then is to include the gem in the Gemfile (and Gemfile.lock) but only require it outside RubyMine.

gem 'debugger', {group: [:test, :development]}.
    merge(ENV['RM_INFO'] ? {require: false} : {})

---

The above code is from this comment on the JetBrains bug tracker, through this comment on a similar question.

It checks for the presence of the RM_INFO environment variable, which is set by RubyMine. The important thing is that it only affects whether the gem is required and thus should not change Gemfile.lock between installs.

Answer 3

I may have an even better solution that seems to be working for me in my Rails 4 app...

In your Gemfile, move all your debugging-related gems to their own group, as such:

group :pry do
  gem 'pry', '>= 0.10.0'
  gem 'pry-debugger', '>= 0.2.3'
  gem 'pry-highlight', '>= 0.0.1'
end

In config/application.rb you will a find something like the following:

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

Add the following just below that:

Bundler.require(:pry) unless ENV['RM_INFO'] || Rails.env.production?

You may wish to modify the unless condition to suit your needs, but the important part is that RubyMine will set RM_INFO, which you can use to detect and therefore exclude gems from being required.

This will eliminate the ping-pong effect of bundling in RubyMine vs. command line, so this should work well in a mixed-IDE team.

One last note, if you're deploying to Heroku, you might want to exclude the :pry group from being installed on deploy:

 $ heroku config:set BUNDLE_WITHOUT="development:test:pry"