If I have a Gemfile that is
source 'https://rubygems.org'
gem "heckle", "~> 2.0.0.b1"
gem "reek", "~> 1.3.2"
Then I get the error message
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Bundler could not find compatible versions for gem "ruby_parser":
In Gemfile:
reek (~> 1.3.2) ruby depends on
ruby_parser (~> 3.1.1) ruby
heckle (~> 2.0.0.b1) ruby depends on
ruby_parser (2.3.1)
Is it possible to tell Bundler that heckle and reek don't need to work with each other, and therefore it's ok to have two versions of ruby_parser?
For those unfamiliar with the two gems involved, heckle and reek are both gems that provide executables that analyse source code. They don't need to be required by code.
Related
We are attempting to install foreman on a raspberry as a demo for installation on larger machines such as the cubietruck. We have problems building the foreman-installer from source:
bundle install --without mysql2 pg test --path vendor
Your Gemfile lists the gem gettext_i18n_rails_js (>= 0.0.8) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.
Your Gemfile lists the gem gettext (~> 2.0) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.
Your Gemfile lists the gem locale (<= 2.0.9) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.
Your Gemfile lists the gem minitest (~> 4.7) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.
Fetching gem metadata from https://rubygems.org/........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...............................................
Could not find gem 'capybara (~> 2.0.0) ruby' in the gems available on this
machine.
We have already manually installed capybara using gem and can locally see it:
sudo gem list
*** LOCAL GEMS ***
bundler (1.6.2)
capybara (2.0.0)
childprocess (0.5.3)
ffi (1.9.3)
mime-types (2.3)
mini_portile (0.6.0)
multi_json (1.10.1)
nokogiri (1.6.2.1)
rack (1.5.2)
rack-test (0.6.2)
rubyzip (1.1.4)
selenium-webdriver (2.42.0)
websocket (1.0.7)
xpath (1.0.0)
Any ideas what we are missing?
Regards
Stefan
I'm just getting started with CI on my open-source project, and it's all going swimmingly, however Travis is continually failing when it gets to pieces of code that require eventmachine. Eventmachine is specified in the gemspec as both runtime and development dependency (same as wisper), but Travis will not install Eventmachine, causing every build to fail - however, it does install wisper. What's going on? :(
Most recent build that failed
GemSpec Dependencies
..
spec.add_development_dependency 'bundler', '~> 1.5'
spec.add_development_dependency 'rake'
spec.add_development_dependency 'rspec', '~> 2.4'
spec.add_development_dependency 'wisper'
spec.add_development_dependency 'eventmachine'
spec.add_runtime_dependency 'wisper'
spec.add_runtime_dependency 'eventmachine'
Travis YML
rvm:
- 1.9.3
# we don't support 1.9.2
# - 1.9.2
- jruby
- rbx
script: "bundle exec rake"
Rake default task
require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new :spec
task :default => :spec
Log
$ gem --version
2.2.2
$ bundle --version
Bundler version 1.5.3
Applying fix for NPM certificates
install
$ bundle install --deployment
Fetching gem metadata from https://rubygems.org/.........
Fetching additional metadata from https://rubygems.org/..
Installing rake (10.1.1)
Installing wisper (1.3.0)
angler at /home/travis/build/DanPantry/angler did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
duplicate dependency on wisper (>= 0), (>= 0) use:
add_runtime_dependency 'wisper', '>= 0', '>= 0'
Using angler (0.0.1) from source at .
Installing timers (1.1.0)
Installing celluloid (0.15.2)
Installing nio4r (1.0.0)
Installing celluloid-io (0.15.0)
Installing diff-lcs (1.2.5)
Installing formatador (0.2.4)
Installing rb-fsevent (0.9.4)
Installing rb-inotify (0.9.3)
Installing listen (2.7.1)
Installing lumberjack (1.0.4)
Installing thor (0.18.1)
Installing guard (2.5.1)
Using bundler (1.5.3)
Installing guard-bundler (2.0.0)
Installing rspec-core (2.14.8)
Installing rspec-expectations (2.14.5)
Installing rspec-mocks (2.14.6)
Installing rspec (2.14.1)
Installing guard-rspec (4.2.8)
Cannot write a changed lockfile while frozen.
Your bundle is complete!
It was installed into ./vendor/bundle
$ bundle exec rake
/home/travis/.rvm/rubies/ruby-1.9.3-p484/bin/ruby -S rspec ./spec/remote_spec.rb
/home/travis/build/DanPantry/angler/lib/angler.rb:5:in `require': cannot load such file -- eventmachine (LoadError)
NOTE: Even without add_runtime_dependency, Travis just won't install EventMachine.
The important part of your log is this
angler at /home/travis/build/DanPantry/angler did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
duplicate dependency on wisper (>= 0), (>= 0) use:
add_runtime_dependency 'wisper', '>= 0', '>= 0'
Fix your gemspec, then bundler can install gems specified there. I simple solution would be to remove the development dependency to wisper and rely solely on the runtime_dependency for it.
In my gemspec file:
I have a gem dependency called zconfig that explicitly requires net-ssh version 2.6.8
I'm also using net-sftp, which in turn requires net-ssh version >= 2.6.5
When I bundle install, bundler is smart enough to recognize the needs of both gems and correctly identifies 2.6.8 as the version of net-ssh to install.
net-sftp (2.1.2)
net-ssh (>= 2.6.5)
...
net-ssh (2.6.8)
...
zconfig (0.2.7)
mysql (~> 2.9.1)
mysql2 (~> 0.3.13)
net-ssh (~> 2.6.8)
net-ssh-gateway (~> 1.2.0)
sequel (~> 4.1.0)
sqlite3 (~> 1.3.7)
So far, while testing on the remote server, I've been cloning the project and installing these gems with bundle install --deployment and then running the project with the locally instaled vendor gems using bundle exec ..
However, I'm now done with development and I've packaged the project as a gem and installed it on the remote server. The problem is that when executing the gem ruby doesn't adhere to my Gemfile.lock specification and uses net-ssh 2.7.0, which causes a conflict:
/usr/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:1615:in `raise_if_conflicts': Unable to activate zconfig-0.2.7, because net-ssh-2.7.0 conflicts with net-ssh (~> 2.6.8) (Gem::LoadError)
Is there a way to do something like bundle exec my_gem so that it uses the Gemfile.lock specifications?
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.
My gemspec clearly requires active_support ~> 3.0, but bundler is failing to bundle install saying that my gem requires active_support = 3.0. WTF bundler? Can anyone explain this?
$ gem install code_filter
Successfully installed activesupport-3.0.0
Successfully installed active_support-3.0.0
Successfully installed code_filter-0.1.1
$ gem dependency code_filter
Gem code_filter-0.1.1
active_support (~> 3.0, runtime)
$ bundle
Fetching gem metadata from http://rubygems.org/.......
Fetching gem metadata from http://192.168.10.22/...
Fetching gem metadata from http://rubygems.org/...........
Fetching gem metadata from http://192.168.10.22/..
Bundler could not find compatible versions for gem "activesupport":
In Gemfile:
code_filter (= 0.1.1) ruby depends on
activesupport (= 3.0.0) ruby
json_builder (~> 3.1) ruby depends on
activesupport (3.0.20)
This is not the first time I've run into this, but here's a concrete example:
$ bundle update rails
Fetching source index for http://rubygems.org/
Bundler could not find compatible versions for gem "builder":
In Gemfile:
rails (~> 3.0.0) ruby depends on
builder (~> 2.1.2) ruby
hoptoad_notifier (>= 0) ruby depends on
builder (3.0.0)
So Bundler claims the hoptoad_notifier gem depends on the 3.0.0 version of builder. But that's not the case, it only requires builder >= 0.
$ gem dependency hoptoad_notifier
Gem hoptoad_notifier-2.4.11
actionpack (>= 0, development)
activerecord (>= 0, development)
activesupport (>= 0, runtime)
bourne (>= 0, development)
builder (>= 0, runtime)
nokogiri (>= 0, development)
shoulda (>= 0, development)
Why does Bundler think hoptoad_notifier depends on builder 3.0.0?
Selected bits from the Gemfile and Gemfile.lock:
source "http://rubygems.org"
gem 'rails', '~> 3.0.0'
gem 'hoptoad_notifier'
...a bunch of testing gems, custom gems, etc.
Gemfile.lock
GEM
remote: http://rubygems.org/
specs:
actionmailer (2.3.14)
actionpack (= 2.3.14)
...
builder (3.0.0)
...
cucumber (1.2.0)
builder (>= 2.1.2)
diff-lcs (>= 1.1.3)
gherkin (~> 2.10.0)
json (>= 1.4.6)
...
hoptoad_notifier (2.4.11)
activesupport
builder
... no other mentions of builder
I consider this more of a workaround than an answer to the question, so I'll leave the question open for a while to see if there's a better answer.
I found different ways to attack the problem (using bundle update on specific gems, modifying the Gemfile, running bundle install), but continued to run into some form of this error for various dependencies. It really seems like an issue with Bundler. (I'm using v1.0.22, upgrading made it worse.) Ultimately, what got me out of this mess was to delete the Gemfile.lock and run bundle install, letting Bundler resolve all the dependencies from scratch. Now of course, this is far from ideal, since the whole reason you have a lock file is to lock down your app's dependencies. But since I'm upgrading Rails to v3 anyway, it was acceptable in this case.