I have a site running with nginx/unicorn/sinatra (bundler/rvm).
After my last bundle update, I am getting an error:
in `raise_if_conflicts': Unable to activate dm-serializer-1.2.1, because multi_json-1.3.5 conflicts with multi_json (~> 1.0.3)
My Gemfile is:
source "http://rubygems.org"
gem 'unicorn'
gem 'sinatra'
gem 'datamapper'
gem 'dm-mysql-adapter'
gem 'haml'
gem 'sass'
gem 'omniauth-twitter'
Gemfile.lock does not have any reference to multi_json 1.0.3
Any ideas?
Solution was:
check Gemfile.lock to see which gem(s) bring in later version (in this case - omniauth-twitter)
Find a version of 'offender' that does not require too high version
Rollback later versions, lock to a proper version in Gemfile
In this particular case, Gemfile that works needed lines:
gem 'omniauth-twitter', '0.0.9'
gem 'multi_json', '~> 1.0.3'
One of the gems in your bundle has an older version of multi_json as a dependency it looks like. See if bundle viz tells you. You'll need to install the ruby-graphviz gem and graphviz itself if you don't have them installed already, though.
Another way to see what's up is to add multi_json to your gemfile at the version you're trying to upgrade to, then do a bundle install and see what errors come out.
This is how to fix this problem:
rvm uninstall multi_json
It will tell you that you have many versions installed, show you a list of them, and ask you which one exactly you want to uninstall.
Try the first one, if it tells you that it is used by some other gem, try the second one, and so on. Keep deleting all the unused versions until only one remains.
This is how I do it, but there may be some clearner solution. If anyone knows it, thanks for sharing it with us.
Related
When I run gem list bundler, I get the following result
+ gem list bundler
*** LOCAL GEMS ***
bundler (default: 2.3.22, default: 2.1.4)
How is it possible that two versions are marked as default? Is there a way to update the default one?
Context
The reason I ended up looking into which is the default Bundler version is that I've been running into this warning on a self-managed CI machine on and off for a while:
Gem::LoadError: You have already activated bundler 2.3.22 [or whichever latest version is available], but your Gemfile requires bundler 2.1.4.
I looked into my Gemfile.lock and it requires bundler like this:
bundler (>= 1.12.0, < 3.0.0)
So I'm guessing at some point, Bundler activated (which I believe means selected for runtime use) version 2.1.4 because that was the default available one.
I hope to be able to forever prevent that error by forcing the latest version of bundler to be the one used at runtime, but I'm not sure how to achieve it.
That is, how can I get the gem list bundler output to not show default: 2.1.4?
Thanks for your help!
To delete the duplicate default versions
gem environment
you will find the installation directory:
INSTALLATION DIRECTORY: /home/seb/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0
in /specifications/default you will find your .gemspec files, you will remove your duplicate one
rm bundler-2.2.31.gemspec
to verify: gem list bundler
(2.2.31, 2.2.29, default: 2.2.15)
you can update the default version with gem install bundler:2.3.18 --default but it appears that bundler use a arbitrary version that fit his needs. If you want use a specific version to bundle the Gemfile, you add it in your gemfile
gem "bundler", "~> 2.3"
it will appear at the end of the gemfile.lock
BUNDLED WITH 2.3.18
The gem hashdiff has problems with another gem using the same namespace, it gives the deprecation warning:
The HashDiff constant used by this gem conflicts with another gem of a similar name. As of version 1.0 the HashDiff constant will be completely removed and replaced by Hashdiff. For more information see https://github.com/liufengyun/hashdiff/issues/45.
(The link is to a long conversation, even reading it I am not sure how to upgrade this particular gem)
My /Gemfile does not have hashdiff in, however there is a gem which depends on it, in /Gemfile.lock there is hashdiff (0.4.0).
To force hashdiff to upgrade to 1.0, I added gem 'hashdiff', '~> 1.0' to /Gemfile and ran bundle update hashdiff but:
Fetching gem metadata from https://rubygems.org/.
Could not find gem 'hashdiff (~> 1.0)' in any of the gem sources listed in your Gemfile.
Alas rubygems does not have version 1.0.
How are we people dealing with the deprecation warning? Ignoring it until the gem becomes available? Or something else?
Bundler doesn't consider beta versions of a gem when solving dependencies unless you explicitly tell bundler to use such a beta version.
I would just add that gem together with a comment to my Gemfile
# FIXME: Force bundler to use the beta version of the hashdiff gem
# `hashdiff` is a dependency of the `webmock` gem. Feel free to remove
# the following line from this Gemfile as soon as hashdiff 1.0.0 is
# officially released.
gem 'hashdiff', '>= 1.0.0.beta1'
gem 'webmock'
and then run bundle update hashdiff.
Update
Version 1.0.0 of the hashdiff gem was released on 2019-07-15. Therefore this workaround is not needed anymore and a bundle update hashdiff – without the need to update the Gemfile first – should solve the issue.
I'm fairly new to rails and I encountered this gem conflict, while running bundle install, between ActiveSupport and threetaps-client (which I need to use for my project).
I tried removing the Gemfile.lock file and running bundle install again but it gave me the same error message again. I also tried running bundle update which also gave the same result :(
Bundler could not find compatible versions for gem "activesupport":
In snapshot (Gemfile.lock):
activesupport (3.2.13)
In Gemfile:
threetaps-client (>= 0) ruby depends on
activesupport (~> 3.0.0) ruby
Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
The issue here is that you are using Rails 3.2 (and thus, activesupport 3.2). However, threetaps-client is version locked to rails/activesupport 3.0.x. The easiest solution to this would be to downgrade Rails to 3.0 in your Gemfile with:
gem "rails", "~> 3.0"
And then remove the Gemfile.lock and bundle install again. You should be good to go after that.
EDIT
I was able to get the gem to support activesupport 3.2 (I think). The tests do not pass on this branch, but they did not pass on master either. I assume this probably has to do with credentials or something. Update your Gemfile to use this repo for threetaps-client
gem "threetaps-client", git: "git#github.com:ehowe/3taps-Ruby-Client"
Insert required "your mileage may vary" warning here.
I just got Ruby motion, and I wanted to try out Cocoapods. I installed it just as it asks on the website:
http://www.rubymotion.com/developer-center/articles/cocoapods/
I add
require 'motion-cocoapods' to my simple 'Hello' project. And I get this error when trying to rake it:
rake aborted!
Unable to activate cocoapods-0.16.1, because rake-10.0.3 conflicts with rake (~> 0.9.4)
I guess this has something to do with my version of rake, but I have no idea what I need to do to fix this problem. Please help!
This is caused by having a version of rake newer than 0.9.x installed. When you just run rake, it loads up the newest version (10.0.3 in your case). Then, when the cocoapod gem tries to load, it tries to activate rake 0.9.x and fails (the ~> 0.9.4 means that it will accept any version starting with 0.9.).
One solution would be to completely remove the rake gem and install the 0.9.4 version explicitly:
gem uninstall rake
gem install rake --version '0.9.6'
However, this could become an issue if you have any other projects that require a newer version of rake. A better solution would be to use Bundler:
gem install bundler
Create a Gemfile in your project folder containing:
source :rubygems
gem 'rake'
gem 'motion-cocoapods'
Add the following to Rakefile, immediately under the require 'motion/project' line:
require 'bundler'
Bundler.require
Then run bundle install from the console. This will lock this specific project on rake 0.9.6. The only catch is that you'll probably need to prefix all of your rake commands with bundle exec.
I was able to solve this issue by following the steps on this japanese blog:
http://blog.amacou.net/post/37702092871/rubymotion-cocoapods-rake
First uninstall:
gem uninstall motion-cocoapods
gem uninstall cocoapods
download cocoapods :
git clone git://github.com/CocoaPods/CocoaPods.git
find the gemspec file
and change this:
s.add_runtime_dependency 'rake', '~> 0.9.4'
to this:
s.add_runtime_dependency 'rake', '> 0.9.4'
then install it as a gem
rake gem:install
then reinstall motion-cocoapods:
gem install motion-cocoapods
My feeling is this is a hack though, and I'm worried it could cause problems else where. If anyone has a better answer, please post it.
I installed mocha using gem install mocha and it did install successfully. There are no version requirements of a specific version in my GEMFILE.
I still get the error :
Could not find mocha-0.10.3 in any of the sources
Anyone knows why ?
To install gems from rubygems.org, you need to set the source :rubygems in the Gemfile, to make it look something like
source :rubygems
gem "mocha"
the problem might also be that your Gemfile.lock requires an older version due to some dependencies, than the one you've installed via gem install mocha, assuming that's what you did.
Showing contents of your Gemfile might help solve this easier though.
Looks like that version of mocha was yanked from RubyGems, so you will need a newer version. If you're not hardlocked to a specific version in your Gemfile, then try a bundle update mocha to update your Gemfile.lock. Otherwise, make sure you're using the spermy operator to specify the version in your Gemfile:
gem "mocha", "~> 0.10.5"