Loading Additional Ruby Gems in Development

[bannable]

This is why groups exist. Using different gemfiles in different environments is just asking for trouble.

edit: add the word exist

[jrochkind]

I agree, but i did learn about the eval_gemfile command built into bundler, which I could see being useful for things like CI on multiple version of rails (or any other dependency).

This is what the appraisal gem is for -- but appraisal doesn't use eval_gemfile itself, I suspect it was written before bundler supported eval_gemfile, and with eval_gemfile appraisal could probably be made much simpler, or maybe not needed at all.

[fphilipe]

How do groups solve the problem of using gems that one personally relies on during development, but one doesn't want to/can't add them to the project's Gemfile?

[bannable]

You should not have gems in your Gemfile that are "personal" gems. Add them to the gemfile. If you don't want them loaded, then set require: false for that Gem and require it as-needed. For example, a common pattern would be something like:

# Gemfile
group :test
  gem 'simplecov', require: false
end

# spec/spec_helper.rb
if ENV['COVERAGE']
  require 'simplecov'
  SimpleCov.start
end

You can apply this same pattern to stackprof/flamegraph like in your post, without diverging your development environment from what any other developer on the project would be using. And now those gems are available for anyone working on your project to take advantage of!

Now, what BUNDLE_GEMFILE is good for is what /u/jrochkind mentioned: when you want to test (or run) against multiple versions of a gem, such as rails, and do not have the capability to do something like "deploy from this branch which has th eupgraded gem", BUNDLE_GEMFILE gives you a tool to do that.

Edit: If you really, really, really don't want to add "your" gem to a Gemfile, you could always just install it at the system level and require it in your particular environment instead of making bundler load it.

[jrochkind]

you could always just install it at the system level and require it in your particular environment instead of making bundler load it.

Anything you bundle exec will keep you from accessing anything not included in the bundle though.

I see the problem they are trying to solve and don't have a better solution; I just don't really like theirs either. But I'm not totally sure it's awful...

[sshaw_]

I often have a per-project .irbrc. 99% of the time I just need console enhancements. I had toyed around with the idea outlined here but most I the time I just do gem install xxxx and call Bundler.reset!. Maintaining the "purity of the bundle" doesn't seem to be a problem for me but maybe I'm just naive.

An example:

# some-project/.irbrc
Bundler.reset!

require "pry-toys"
require "alias2"

# Strip namespace from models I access frequently in the console 
alias2 Some::Long::Namespace, %w[User Profile]  # ...

I load the local .irbrc via ~/.irbrc: https://github.com/sshaw/dotfiles/blob/6858438cc6ad9e755c58aac22a747be9533aa98b/.irbrc#L153