Managing Conflicting Versions of Ruby Gems

Managing conflicting versions of ruby gems

To be blunt, you can't have two versions of the same gem loaded at the same time.

Bundler does a good (ish) job of looking through all of the required gems and finding a solution to the various overlapping dependencies, but even so it is limited to only loading one version of a gem at a time.

This leads to plugin developers constantly having to update to support any changes that are made in dependent gems in order to avoid just the situation you describe.

(Don't get me started on the screw up that results from the various competing JSON implementations and the pain you have to go through when you have several gem dependencies all requiring different ones.)

Managing multiple versions of a Ruby Gem

You should use RVM to manage multiple versions of ruby and gems.
Visit followings links to have an idea of rvm and to install.

https://rvm.io/

https://rvm.io/rvm/install/

How to manage multiple Ruby apps with conflicting gem versions?

Bundler Handles Multiple Gem Versions on System

Bundler can handle this use case just fine. Your explicit gem dependencies go into your Gemfile, and all gem versions within the bundle are then stored in the Gemfile.lock file.

As a general rule, your gems will be installed in GEM_HOME. Multiple versions of a gem can be installed at the same time, and require bundler/setup takes care of ensuring that the correct versions (as specified in your Gemfile.lock) are made available to your Ruby application.

However, unless you use binstubs, gemsets, or special invocations like <gem> _<version>_ [args], you will need to run bundle exec <gem> from the command line in order to use the correct version as specified by your bundle.

conflicting ruby gems

There's probably no elegant solution to the problem. If you really need the two gems working side by side I think your best option is to fork one of them (or possibly both) and use your fork. This is how I'd go about it:

• If either gem is hosted on Github then fork it, or if both are on Github fork the one that seems to be the least work.
• If neither gem is on Github, see if you can get hold of the source (grabbing it from the gem is a possibility, but finding the real repository might be helpful as there may be other files there that are not included in the gem), and put it in a repository on Github. Make sure the gem's license allows this (which it almost certainly does if it's one of the common open source licenses).
• Make your changes.
• Make sure there is a .gemspec file in the root of the repository, the next step will not work otherwise.

• Use Bundler to manage your projects dependencies. Instead of specifying the dependency to the library you've modified as

  gem 'the_gem'
  

  specify it like this:

  gem 'the_gem', :git => 'git://github.com/you/the_gem.git'
  

  (but change the URL to the repository to the actual one)

• Send an e-mail to the maintainer of the gem you modified and ask him or her to consider merging in your changes in the next release.

Bundler makes it really easy to use alternative versions of gems with minimal hassle. I often fork gems, fix bugs or add features, change my Gemfile to point to my version, then ask the maintainer to merge in my changes. When, or if, that happens I simply change my Gemfile back to just refer to the official version of the gem.

An alternative strategy, if the maintainer does not want to merge in your changes and you want to distribute your version to others is to push up your version to Rubygems as a new gem, but in that case prefix the gem name with your name, or some other string that identifies your gem as a variant.

Managing conflicting dependencies in Gemfile.lock

Just define the specific version of the gem to a required version by adding the following line in the gemfile:

gem 'net-ssh', '2.6.8'

or in the thinegem.gemspec:

spec.add_dependency 'net-ssh', '2.6.8'

And if you did add the gemfile.lock into the project, it shell be used during a deployment anyway.

Gem dependency conflict

This answer is very late, but you inadvertently upgraded the twitter gem, which was yanked as gruzy notes in a comment here.

Just specify another repo, with a tag that's not broken for you and does not conflict with faraday. For me, this was:

gem 'twitter', :git => 'https://github.com/sferik/twitter.git', :tag => 'v2.2.0'

You probably just replace v2.2.0 with v2.5.0, and the breakage should be gone.

---

Related Topics