CODEWITHSUNDEEP
rubyrubygemsbundler
arikfr
arikfr

Reputation: 3361

How to use gems not in a Gemfile when working with bundler?

When using bundler with a project in general and Rails specifically, you have access only to gems defined in your Gemfile. While this makes sense, it can be limiting. Mostly I find it limiting when I want to use a certain RSpec formatter that the rest of the team doesn't use. Unless it's in the Gemfile, it isn't accessible.

Any way around it or I have to add it to Gemfile?

Update: my problem wasn't Bundler but Spork. When running RSpec without Spork I had no problem of using whatever formatter I wanted.

Update #2: it looks like that using Bundler is still the cause of the problem. The difference between using Spork and not using Spork, is that when running RSpec without Spork, it loads the formatter before loading your project and getting into the Bundler "sandbox".

With Bundler:

$ bundle exec irb
>> require 'fivemat'
LoadError: cannot load such file -- fivemat

from (irb):1:in `require'
from (irb):1
from /Users/arikfr/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'

Without Bundler:

$ irb
>> require 'fivemat'
=> true

Upvotes: 27

Views: 8047

Answers (6)

b f
b f

Reputation: 71

I believe the gem Devpack provides the functionality you are looking for.

The gem allows you to add a single gem to your Gemfile which will permit any developer to configure their own preferred set of development gems either for an individual project or globally by creating a .devpack file containing a list of gems.

(I am the author of this gem; I came across this post while developing it so thought it may be worth adding).

Upvotes: 1

Andres Leon
Andres Leon

Reputation: 141

Add to .gitignore

Gemfile.local
Gemfile.local.lock

Add to the project a Gemfile.local.sample file with the following content:

# Include gems that are note meant to be part of the project but for development purposes
# That's why Gemfile.local and Gemfile.local.lock must be git-ignored

# To use these gems:
#   1. Create a "Gemfile.local" file (at same level of "Gemfile")
#   2. Prepend "BUNDLE_GEMFILE=Gemfile.local" before "bundle install" or "bundle exec rails c" and so forth.

eval_gemfile "./Gemfile"

group :development, :test do
  # Suggested gems
  gem "awesome_print", require:"ap"
  gem "hirb"
  gem "pry"
  gem "pry-byebug"
  gem "pry-rails"
  gem "meta_request"

  # My gems
  gem "fivemat"
end

Upvotes: 2

Holger Just
Holger Just

Reputation: 55908

In ChiliProject we allow users to create a Gemfile.local which is included into the main Gemfile on load. This allows users to specify additional gems without having to change our Gemfile to ease updates.

For that, we have included the following code at the bottom of our Gemfile.

gemfile_local = File.expand_path('Gemfile.local', __dir__)
if File.readable?(gemfile_local)
  puts "Loading #{gemfile_local}..." if $DEBUG
  instance_eval(File.read(gemfile_local))
end

The Gemfile.local itself is excluded from the repository via .gitignore.

Upvotes: 22

Derek Kraan
Derek Kraan

Reputation: 129

You can use something like this in your Gemfile:

gem 'foo' if ENV['ENABLE_FOO_GEM']

Then just set ENABLE_FOO_GEM in your environment.

export ENABLE_FOO_GEM=1

The gem will be disabled by default, but easily turned on (permanently) by anyone who wants to use it.

Upvotes: 1

Matt
Matt

Reputation: 10564

I assume that none of these answers have been chosen as correct because they don't do a great job of solving the problem: having additional gems that you can use that by default don't require any changes to files already in the repository to achieve. That is, you don't have to modify any files, and you don't have to live with remembering not to check in your local changes. Here's how I do it.

The idea is basically inverting the dependencies of Holger's answer, such that there's no need to modify the shared Gemfile. Bundler allows one to specify which file is to be used as the gemfile, but strangely the documented methods do not apparently work with its configuration file and will not be fixed. There is a somewhat obscured feature of Bundler that any of the configuration options can be set in an environment variable or passed on the command line. Running all of your commands as bundle [command] --gemfile [yourgemfile] or BUNDLE_GEMFILE="[yourgemfile]" bundle [command] will cause Bundler to read whatever gemfile you want it to. I highly recommend using the environment variable approach, and either creating an alias or exporting the variable for your current session, particularly as I was unable to use the command line switch with the "exec" command.

Therefore, I run rspec like this: BUNDLE_GEMFILE="[mygemfile]" bundle exec rspec [filename], and I have the first part of this aliased as bem in my bashrc. Works like a charm.

Then, you should setup your source control to ignore your Gemfile, either in the project's .gitignore or, to keep the project entirely hygienic without changing even its .gitignore, to your personal global ignore file (which is by default in ~/.config/git/ignore and has the same format as a project's gitignore file).

One other thing to note is that Bundler will create a lockfile based on the Gemfile's name. This is super handy, as it keeps you from overwriting your project's Gemfile.lock if it's checked in, but you need to ignore this new lock file as well. If your gemfile is Foo.bar, look for Foo.bar.lock.

Finally, you can do something similar to Holger's suggestion in your custom Gemfile:

source "http://rubygems.org"
gem "fivemat"
instance_eval(File.read(File.dirname(__FILE__) + "/Gemfile"))

and you're good to go, as long as you remember to specify your Gemfile.

Upvotes: 16

Boris
Boris

Reputation: 3253

In case you still decide to do this (horrible idea):

You can add ruby code to your Gemfile to load a ~/.gemfile (or such) if it exists.

Something like:

eval(IO.read('~/.gemfile'), binding) if FileTest.exists?("~/.gemfile")

Upvotes: 0

Related Questions