Defect #17828

Could not find gem 'mocha (~> 1.0.0) ruby'

Added by Tomasz Zieleniewski about 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Baptiste Barth% Done:

0%

Category:Gems support
Target version:2.6.0
Resolution:Fixed Affected version:2.5.2

Description

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

Gemfile.lock (5.03 KB) Jean-Baptiste Barth, 2014-09-12 22:44

Associated revisions

Revision 13411
Added by Jean-Baptiste Barth about 3 years ago

Add a constraint on "shoulda-matchers" version (#17828).

This helps bundler find its dependencies in case shoulda-matchers v1.4.2 is
already installed. In such a case bundler breaks while it shouldn't.

History

#1 Updated by Jean-Baptiste Barth about 3 years ago

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.

#2 Updated by Tomasz Zieleniewski about 3 years ago

I checked config twice. Firstly, with existing config which excludes groups as well and secondly by removing the config.
The bundle config output:

Settings are listed in order of priority. The top value will be used.
without
Set for your local app (../.bundle/config): "development:test" 

#3 Updated by Jean-Baptiste Barth about 3 years ago

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!

#4 Updated by Jean-Baptiste Barth about 3 years ago

#5 Updated by Tomasz Zieleniewski about 3 years ago

  • Status changed from New to Resolved

Thank you Jean, downgrading the shoulda-matchers to the 1.4.1 version did the job.
Godspeed.

#6 Updated by Jean-Baptiste Barth about 3 years ago

  • Status changed from Resolved to Closed
  • Assignee set to Jean-Baptiste Barth
  • Target version set to 2.6.0
  • Resolution set to Fixed

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.

Also available in: Atom PDF