Project

General

Profile

Actions
Copy link

Defect #17828

closed

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

Added by Tomasz Zieleniewski over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Jean-Baptiste Barth
Category:
Gems support
Target version:
2.6.0
Start date:
Due date:
% Done:

0%

Estimated time:
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

Files

Gemfile.lock (5.03 KB) Gemfile.lock Jean-Baptiste Barth, 2014-09-12 22:44
Actions
Copy link
 #1

Updated by Jean-Baptiste Barth over 10 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.

Actions
Copy link
 #2

Updated by Tomasz Zieleniewski over 10 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"

Actions
Copy link
 #3

Updated by Jean-Baptiste Barth over 10 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!

Actions
Copy link
 #5

Updated by Tomasz Zieleniewski over 10 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.

Actions
Copy link
 #6

Updated by Jean-Baptiste Barth over 10 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.

Actions
Copy link

Also available in: Atom PDF