5

最近実行しようとしましたbundle updateが、コアの1つが100％でスタックしていました。RVMジェムセットの削除を含め、すべてをリセットしようとしましたが、何も役に立ちませんでした。

私bundle install --verboseは何が起こっているのかを見ていたのですが、この時点でプロセス全体が停止しました。

Unmet Dependencies: ["spicycode-rcov", "tenderlove-frex"]
Fetching gem metadata from http://rubygems.org/
Query List: ["spicycode-rcov", "tenderlove-frex"]
Query Gemcutter Dependency Endpoint API: spicycode-rcov tenderlove-frex
Fetching from: http://rubygems.org/api/v1/dependencies?gems=spicycode-rcov,tenderlove-frex
HTTP Success
Query List: []

どうすればこれを解決できますか？

4

1 に答える 1

8

私はこの振る舞いに何度か遭遇しました。Bundlerはスタックしていない可能性がありますが、可能性のあるgemバージョンの縮退して大きな検索スペースを探索しています。env varを設定することにより、可能性を評価する方法に関する詳細なデバッグ情報を取得できますDEBUG_RESOLVER=1。アルゴリズムとリゾルバートレースの出力を理解するには、「Bundlerはどのようにバンドルしますか？ 」をお読みください。

Bundlerが一貫してバックトラックしていたトレースからgemを特定し、多くの異なる候補バージョンを再試行し、バージョンをいくつかの最近のバージョンよりも大きく制限することで、問題を回避しました。これにより、Bundlerは検索スペースを大幅に削減し、評価を迅速に完了することができます。もちろん、追加する制約により、別のgemの要件との解決できない競合が発生する可能性があります。その場合、互換性があるまで制約を段階的に緩和できます。

私には、これらの縮退した解決条件の1つに戻り、それを一連の依存関係とバージョン履歴に変換して、すべて公開できるようにする個人的なTODOがあります。これにより、再現可能な問題をBundler開発者に送信できます。（私たちの宝石の多くは私たちの会社にプライベートです。）ソースのこのコメントは、アルゴリズムが常に妥当な時間で完了すると彼らが考えていることを示していますが、経験的に、数時間の計算では解決できない有効な解決策がある困難なケースがあります。

あなたの状況が私のものに似ていることが判明したが、完全に公開gemに依存している場合、問題のgemfileとgemsetを公開し、問題をBundlerに送信して、アルゴリズムを深く知っている人ができるようにすれば、コミュニティへのサービスになります。それを改善。

問題＃2030は、リゾルバーが実際に無限ループでスタックするバグがある可能性があることを示しています。その証拠が見られる場合、特に複製ケースがすでに提出されているケースよりも小さい場合は、gemfileをその問題に提出することをお勧めします。

于 2013-01-29T15:34:29.607 に答える