Gemfile Twitter + Faraday - ruby-on-rails

In my Gemfile
source 'https://rubygems.org'
ruby '2.1.0'
gem 'rails', '4.0.1'
gem "faraday"
gem "faraday_middleware"
gem "twitter", github: 'sferik/twitter'
if I run
$ bundle install
I get
Bundler could not find compatible versions for gem "faraday": In
Gemfile:
twitter (>= 0) ruby depends on
faraday (~> 0.9.0) ruby
faraday (0.8.9)

TL;DR: Try running bundle update.
Bundler tries to find gems that match in such a way that all their dependencies also match. So consider this:
gem A v1 depends on B v1
gem A v2 depends on B v2
gem C v1 depends on B v1
there is no version of C that knows how to handle B v2.
In this case, Bundler will choose (or even downgrade) A to v1, so that you can A and C running next to each other.
However there are a couple of things that might prevent this from happening, and that will cause the error you are seeing:
There is no A v1, so no match can be made at all. You're stuck in this case, those gems will not work together at all.
You've already installed A v2 and you are adding C later. This means Bundler needs to downgrade A, but it doesn't do downgrades/upgrades when only running bundle install. You'd have to specifically say that it needs to recalculate the dependencies by running bundle update A or for all the gems in your gemfile: bundle update.
One of the gems is from a git repository. Git repositories don't really have versions like gems hosted on rubygems.org do. This means that Bundler will only fetch the latest version and cannot downgrade that gem. You need to specify a branch or revision manually in this case.
My guess is that you are looking at scenario 2. You've already installed (and locked down on) version 0.8.9 of faraday. By adding twitter, your previous lock needs to be updated.
Be careful of running bundle update without arguments however. It will try to get the latest versions of every gem in your gemfile, which might not be what you want.

Related

Two separately namespaced Gemfiles in one Rails app?

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.
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.

Conflicting dependency

I have a conflicting dependency:
Gem A depends on Gem B 2.0
But
Gem C depends on Gem B 1.5
Should I force like this:
gem 'B', '~> 1.5'
All of my other gems are using Gem B 2.5 (the latet version) without problem though, so can I do something like this in my Gemfile?:
gem 'B' # 2.5
gem 'A', dependency: 'b 2.0'
gem 'C', dependency: 'b 1.5'
# gems happily use B 2.5
Update, my exact problem:
rails-observers(>=0) ruby
activemodel(~> 4.0)
jquery-scrollto-rails(>=) ruby
activemodel(~> 3.1.0)
My gemfile isn't enfocring any dependencies at all. No version number option.
bundle install
completes okay but
bundle update
results in the error above
Fork jquery-scrollto-rails on github and upgrade the version. Run it's testsuite. If it runs make a pull request and until it's accepted use your version from github.
If it's not running, then -
Don't complain, fix ;)
Edit
They have a newer version which supports railties 3 < 5
Add this to your Gemfile
gem 'jquery-scrollto-rails', '~> 1.4.3'
Then run $ bundle install
See rubygems
NOTE:
I recommend always using version specifications in your Gemfile. The most optimistic strategy is just by fixing them to the minor version e.g gem 'jquery-scrollto-rails', '~> 1.4'. This is a tremendious help for bundler, which has an np-complete problem to solve. In theory according to Semver there should be no incompatible changes on minor version updates and you could have fixed your problem just by running $ bundle update. A lot of gems do follow this convention, but there are blacksheeps

Bundler fails because it can't find compatible version of faraday gem

I'm trying to install a the instagram-ruby-gem but bundler keeps failing with this error:
Bundler could not find compatible versions for gem "faraday":
In Gemfile:
instagram (>= 0) ruby depends on
faraday (< 0.9, >= 0.7.4) ruby
instagram (>= 0) ruby depends on
faraday (0.9.0)
Here's my Gemfile:
gem 'instagram', git: 'https://github.com/larrylv/instagram-ruby-gem.git'
I am using this specific fork because it fixes the faraday version to be compatible with Rails 4. See the commit here, but here's the change:
- s.add_runtime_dependency('faraday', ['>= 0.7', '< 0.9'])
+ s.add_runtime_dependency('faraday', '>= 0.7.4', '<= 0.9.0')
I already tried bundle update. That did not work. The only faraday version installed is faraday 0.9.0.
I downloaded the forked gem, built it and then installed it. It looks like it went through without any issues on my end. So it is something to do with the environment or a gem conflict issue. I'd check to make sure you don't have any other versions of the gem installed. Do you use RVM by any chance and use gemsets with RVM? As a last resort you could delete the Gemfile.lock, but that is not really recommended. You could look at the Gemfile.lock file as well and look at the faraday references. Perhaps other gems need a certain version and the forked gem you use requires another version? I have run in to that before. It is not fun to try and resolve.
Mike Riley

How to use rails 3.2 engine in rails 4.1 engine development?

When developing rails 4.1 engine module_infox, there include gem authentify which is developed in rails 3.2 in module_infox's gemfile:
gem 'authentify', :path => '../authentify'
Gem authentify sits locally and its gemfile.lock was deleted to remove the version lock.
When bundle install under module_infox, there is an error:
$ bundle install
Fetching gem metadata from http://rubygems.org/.........
Fetching gem metadata from http://rubygems.org/..
Resolving dependencies...
Bundler could not find compatible versions for gem "rails":
In Gemfile:
authentify (>= 0) x86-mingw32 depends on
rails (= 3.2.12) x86-mingw32
module_infox (>= 0) x86-mingw32 depends on
rails (4.1.0.beta1)
Based on our reading, old version gem can be used in newer version gem. Both gemfile.lock in authentify and module_infox were deleted before bundle install. But there is the same error. What's right way to do so?
I think the specific dependency on Rails 3.2.12 on authentify gem is the reason of conflict.
Solution 1: Direct fix
The most intuitive solution would be changing this hard dependency. Say, revise the gemspec as rails, '> 3.2'.
However, your authentify gem itself may not be ready for Rails 4 yet. So using this would be a bit aggressive.
Solution 2: Use git brach
The better alternative is to add a branch in authentify gem say "rails-4", then change the gemspec as above.
Then you need to specify this git branch in Gemfile.
If you use Github to host this gem
gem 'authentify', git: 'git://github.com/username/authentify', branch: 'rails-4'
If you are not going to opensource this gem, you can still use local path. But you need to setup Bundle to recognize it.
$ bundle config local.authentify ~/Work/git/authentify
Then set it in Gemfile
# gem 'authentify', :github => 'authentify/authentify', :branch => 'master'
I commented out the last line of code because I just copied it from Bundle doc but not verified that before. You can check the doc and experiment by yourself. http://bundler.io/v1.2/git.html

could not find gem spree-stock-manager, source does not contain any versions

I've been searching for a solution to this problem but been unable to find it.
I'm trying to add spree-stock-manager to my vanilla spree test store (1.2.0).
When I run 'bundle install' i get
Could not find gem 'spree-stock-manager (>= 0) ruby' in git://github.com/olivierbuffon/spree-stock-manager.git (at master). Source does not contain any versions of 'spree-stock-manager (>= 0) ruby'
I tried downloading and installing it as a local gem into vendor/gems and also added a specific version to my Gemfile (suggestion from Stackoverflow). Same result only said (= 1.1.0) instead of (>= 0).
I looked into the .gemspec for spree_stock_manager and it said
s.add_dependency 'spree_core', '~> 1.1.0'
so that should include spree_core 1.2.0, right?
Other info:
Mac OSX, rvm, rails 3.2.9
Anyone knows why this happens?
Thanks in advance!
s.add_dependency 'spree_core', '~> 1.1.0'
This indicates that it requires any version of spree_core from 1.1.0 up to, but NOT including 1.2.0.
I would be weary of using this gem for a couple reasons. First, there are no tests associated with it, which tells me the author doesn't care enough about the code to take the time to document the expected behavior. It also won't be easy for others to contribute bug fixes or enhancements without tests. Second, the gem isn't registered at rubygems.org. While not required, this is the standard gem repo and tells me that the author had no intention of actually releasing it publicly.

Resources