Vote #75554
完了Could not find gem 'mocha (~> 1.0.0) ruby'
0%
説明
Hi everybody,
I have a fresh copy of the 2.5 version, checkout from SVN.
As stated in the RedmineInstall I run bundler to manage gems dependencies
bundle install --without development test
I get the following error
Resolving dependencies... Could not find gem 'mocha (~> 1.0.0) ruby' in the gems available on this machine.
It seems for me that somehow bundler is not excluding test group which introduces higher mocha version.
group :test do
gem "shoulda", "~> 3.3.2"
gem "mocha", "~> 1.0.0", :require => 'mocha/api'
if RUBY_VERSION >= '1.9.3'
gem "capybara", "~> 2.1.0"
gem "selenium-webdriver"
end
end
Installing mocha 1.0.0 leads to versions conflict between 0.10.5 and 1.0.0.
Resolving dependencies...
Bundler could not find compatible versions for gem "mocha":
In Gemfile:
shoulda (~> 3.3.2) ruby depends on
shoulda-matchers (~> 1.4.1) ruby depends on
bourne (~> 1.1.2) ruby depends on
mocha (= 0.10.5) ruby
mocha (1.0.0)
Information
Environment: Redmine version 2.5.2.stable.13367 Ruby version 1.9.3-p194 (2012-04-20) [x86_64-linux] Rails version 3.2.19 Bundler version 1.7.2 Environment production Database adapter Mysql2 SCM: Subversion 1.6.17 Git 1.7.10.4 Filesystem Redmine plugins: no plugin installed
journals
Thanks for the detailed bug report! Unfortunately I don't reproduce on my setup easily, but I'll try harder in the next few days.
Just an idea: maybe you have a @.bundle/config@ file that tells bundler to install test dependencies anyway? you should be able to see if bundler has some config issues by issuing a @bundle config@ command.
--------------------------------------------------------------------------------
I checked config twice. Firstly, with existing config which excludes groups as well and secondly by removing the config.
The bundle config output:
<pre>
Settings are listed in order of priority. The top value will be used.
without
Set for your local app (../.bundle/config): "development:test"
</pre>
--------------------------------------------------------------------------------
You should probably remove @Gemfile.lock@ before running commands if it's present.
Here's the Gemfile.lock I get when running a bundle install. I noticed that for me, should-matchers doesn't depend on bourne, which is causing your problem. The only version of should-matchers I found on rubygems.org which depend on @bourne ~> 1.1.2@ is v1.4.2 : http://rubygems.org/gems/shoulda-matchers/versions/1.4.2 ; the dependency has still been discarded because it was posing problems, but still, that's the only explanation I find for this problem: you may already have should-matchers 1.4.2 installed. Try to @gem uninstall shoulda-matchers@ then re-run @bundle install@. Ideally you should start with no gems or separate environments (like RVM which provides gemsets).
Anyway, it's not normal bundler is trying to install those gems as you specified the @--without@ option, and for that I have no explanation sorry :(
Hope this helps!
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Thank you Jean, downgrading the shoulda-matchers to the 1.4.1 version did the job.
Godspeed.
--------------------------------------------------------------------------------
Nice! As this issue pops up from time to time, I added a constraint in the Gemfile to help bundler find its way through ou dependencies chain. See r13411. As it's a minor problem with the "test" gems, I leave it for 2.6.0.
As for the test gems installing while they shouldn't, I don't have any explanation sorry :(
I close this issue for now.
--------------------------------------------------------------------------------