2

I need to require these two gems in my Rails 3.2 app:

gem 'google-adwords-api'
gem 'netsuite'

However, they conflict on the versions of the savon gem. Bundler spits out this:

Bundler could not find compatible versions for gem "savon":
    In Gemfile:
        google-adwords-api (>= 0) ruby depends on
            google-ads-common (~> 0.2.0) ruby depends on
                savon (~> 0.9.1) ruby

    netsuite (= 0.2.6) ruby depends on
        savon (2.3.3)

I absolutely need both gems in my project, so this is what I've tried so far. I've moved the google-adwords-api gem into a custom Rails Engine I named "adx_interface" and mounted it within my Rails app. This engine has it's own Gemfile. If I put this line in my Rails app's Gemfile, then the Bundler error remains:

gem "adx_interface", "0.0.1", :path => "#{File.expand_path(__FILE__)}/../vendor/adx_interface"

Is there some way to namespace this engine so that it's dependencies aren't clashing with the apps dependencies? I've tried excluding the gem "adx_interface" line from the apps Gemfile, but that means I would have to start requiring gems manually instead of relying on Bundler. Is that a viable solution? If so, how do I go about including the google-adwords-api in such a way that it's namespaced properly and it's savon won't clash with netsuite's savon?

For what it's worth, I've personally contacted the author of the google-adwords-api gem. He said he likes the savon 0.9.1 gem and has no plans to ever update to a newer version.

Simone Carletti
  • 173,507
  • 49
  • 363
  • 364
Michael Schneider
  • 21
  • 1

1 Answers1

3

What you are trying to do is exactly against the idea behind Bundler. Bundler exists to help you manage your dependencies and discover conflicts.

There is no clean way to bypass this restriction. The only solution I can think about, is to fork the google-adwords-api gem, bump the dependency and have your Gemfile to point to your custom fork.

Simone Carletti
  • 173,507
  • 49
  • 363
  • 364
  • To elaborate on this, if Bundler _did_ allow this, you're likely to have problems at runtime. The two versions of the gems will define the same classes and modules in different ways, and one will overwrite the other. – Tim Moore Nov 04 '14 at 03:51