I’m running into a gem dependency issue when trying to install the mandrill-api gem in my Rails project.
After adding it to my Gemfile and running bundle install, I get this version conflict error:
Bundler could not find compatible versions for gem "excon":
In Gemfile:
mandrill-api (>= 0) ruby depends on
excon (~> 0.15.4) ruby
heroku-api (>= 0) ruby depends on
excon (0.13.4)
The problem is that mandrill-api needs excon version 0.15.4 or higher, but heroku-api is locked to exactly version 0.13.4. I’ve tried various solutions including removing the heroku gems entirely, but then I get similar conflicts with the fog gem.
Has anyone encountered this type of dependency resolution problem before? What’s the best way to resolve these conflicting version requirements?
Version pinning strikes again. I faced this same nightmare three months ago on a legacy project. The problem? Both gems use exact version specs instead of semantic ranges. Mandrill-api wants excon ~> 0.15.4 while heroku-api locks to 0.13.4 exactly. Run bundle outdated first to see what else might break. Sometimes updating everything shows heroku-api has newer versions that work with higher excon versions. I fixed it by copying heroku-api locally and tweaking its gemspec to accept excon >= 0.13.4. The API changes between those excon versions were tiny, so heroku-api kept working fine. Or just ditch heroku-api altogether - make direct HTTP calls with Net::HTTP or Faraday. Heroku’s Platform API is simple to use directly, and you’ll avoid the middleman gem conflict completely.
Dependency conflicts are a total nightmare. Been there way too many times.
The problem is gem version constraints create dependency hell that’s nearly impossible to fix manually. You can try updating individual gems or running bundle update, but it usually breaks something else.
Here’s what I do instead of fighting gem conflicts - I automate everything with Latenode. You can build workflows that hit both Heroku and Mandrill APIs directly, no Ruby gems needed.
I made a workflow that handles Heroku deploys through their REST API and sends emails via Mandrill’s endpoints. Zero gem dependencies. It handles auth, errors, and retries automatically.
This kills the dependency conflict entirely since you’re making direct HTTP calls instead of using potentially broken gems. Plus you get way better control over your data.
I’ve used this for tons of integration problems where gems clash. Way cleaner than wrestling with version constraints that’ll probably break again next update.
This dependency mess happens way too often. I’ve hit this same issue multiple times.
Both gems have rigid version locks instead of ranges. Real question - do you actually need heroku-api? Most projects added it years ago and forgot about it.
Check what’s using heroku-api in your code. If it’s just deployment scripts or monitoring, replace those calls with simple HTTP requests to Heroku’s REST API. Takes 30 minutes to rewrite and kills the dependency completely.
If you’re stuck with both gems, force a resolution in your Gemfile:
gem 'excon', '~> 0.15.4'
This makes bundler use the higher version. heroku-api will probably work fine with 0.15.4 even though it wants 0.13.4. I’ve done this hack in production without problems.
Worst case - vendor heroku-api locally and update its gemspec to allow newer excon versions. Not pretty but gets you unblocked fast.
Had this exact conflict six months ago updating an old Rails app. Both gems use hard version constraints instead of flexible ranges - creates impossible situations.
First, check if you actually need heroku-api. Most people add it for deployment scripts or one-off tasks that can be done other ways. For basic Heroku operations, the CLI toolbelt usually works better than the Ruby gem.
If you need both gems, try putting heroku-api in a separate Gemfile group and only load it when needed. You could also fork one of the gems temporarily and update its version constraints, but that’s extra maintenance work.
Another option: use the platform-ruby directive in your Gemfile to specify different gem versions for different environments. This isolates the conflict to specific deployment scenarios while keeping your main app working.
Ugh, same thing happened to me last week. Run bundle update excon first - sometimes bundler just needs a nudge to find a version that works for both gems.