我最近尝试运行bundle update，但我的一个核心卡在 100%。我试图重置所有内容，包括删除我的 RVM gemset，但没有任何帮助。
我曾经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: []
我该如何解决这个问题？
我已经多次遇到这种行为。Bundler 可能没有被卡住，而是正在探索可能的 gem 版本的退化大搜索空间。您可以通过设置 env var 获得有关如何评估可能性的详细调试信息DEBUG_RESOLVER=1。阅读“ Bundler 如何捆绑？ ”以了解解析器跟踪的算法和输出。
我通过从 Bundler 始终回溯并重试许多不同候选版本并将版本限制为高于某些最新版本的跟踪中识别 gem 来解决该问题。这通常有助于 Bundler 大大减少搜索空间并快速完成其评估。当然，您添加的约束可能会与另一个 gem 的要求产生无法解决的冲突，在这种情况下，您可以逐步放松您的约束，直到它兼容为止。
我有一个个人 TODO 可以返回到其中一个退化的解决条件，并将其转换为一组可以公开的依赖项和版本历史记录，以便我可以向 Bundler 开发人员提交可重现的问题。（我们的许多 gem 是我们公司私有的。）来源中的这条评论表明他们认为算法总是在合理的时间内完成，但根据经验，有一些困难的案例有有效的解决方案，这些解决方案无法通过数小时的计算来解决。
如果您的情况类似于我的情况，但完全依赖于公共 gem，如果您可以将问题 gemfile 和 gemset 公开并将问题提交给 Bundler 以便深入了解算法的人可以改进它。
问题 #2030表明可能存在解析器实际上陷入无限循环的错误。如果您看到这方面的证据，您可能希望将您的 gemfile 提交给该问题，特别是如果您的重现案例小于已提交的案例。