1

これは初めてではありませんが、具体的な例を次に示します。

$ 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)

そのため、Bundler は hoptoad_notifier gem がビルダーの 3.0.0 バージョンに依存していると主張しています。しかし、そうではなく、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)

Bundler が hoptoad_notifier がビルダー 3.0.0 に依存していると考えるのはなぜですか?

Gemfile と 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
4

1 に答える 1

2

これは質問への回答というよりも回避策であると考えているため、質問をしばらく開いたままにして、より良い回答があるかどうかを確認します。

問題に対処するさまざまな方法を見つけました (特定の gem で bundle update を使用する、Gemfile を変更する、bundle install を実行する) が、さまざまな依存関係に対して何らかの形でこのエラーが発生し続けました。それは本当にBundlerの問題のようです。（私はv1.0.22を使用していますが、アップグレードするとさらに悪化しました。）最終的に、この混乱から抜け出したのは、Gemfile.lockを削除してbundle installを実行し、Bundlerがすべての依存関係を最初から解決できるようにすることでした. もちろん、これは理想とはほど遠いものです。なぜなら、ロック ファイルを作成する理由は、アプリの依存関係をロックダウンするためだからです。とにかく Rails を v3 にアップグレードしているので、この場合は許容範囲でした。

于 2012-12-26T23:00:13.923 に答える