Specifying the same gem twice for development/test and production but different paths

Question

Sometimes you make a gem that is specific to a project. This helps abstract and pull some of the "responsibility" out of the main Rails app and into a more modular place.

The gem would be located here on you application:

gem 'example_gem', path: './example_gem'

You bundle and everything is OK. Now, you git init the gem and store it in its own repo on github. You try doing this to keep it developer friendly:

group :development, :test do
  gem 'example_gem', path: './example_gem'
end

group :production do
  gem 'example_gem', github: 'company/example_gem'
end

You pat yourself on the back for increasing your workflow, but after running bundle you get:

Your Gemfile lists the gem example_gem (>= 0) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.
You cannot specify the same gem twice coming from different sources.
You specified that example_gem (>= 0) should come from source at ./example_gem and git://github.com/company/example_gem.git

The workflow here is to be able to edit the gem in development and when you're done, commit those changes and push them to Github. BUT, when on development, you don't want to have to do a git commit, git push, and a bundle update on your main app just to see a small change.

Does anyone know of a better way to solve this issue?

Answer 1

Yes, there is a better way: First, have the gem as a git gem in all environments

gem :example_gem, :git => '[email protected]:foo/example_gem', :branch => :master #you need to set a branch

Then in your app's folder run

bundle config --local local.example_gem /path/to/gem

This will edit .bundle/config to set this option (make sure this file isn't checked into source control!) and tells bundler to get the gem from that path.

At the point when you are going to push your commits you have to be a little bit careful: if your app depends on not yet committed changes to the gem then clearly things will break. In addition as you commit to the repository for the example gem the rails app's Gemfile.lock will get updated. If you push a Gemfile.lock that references a commit that only exists in your copy of the example_gem repo then other users will be stuck.