我最近尝试运行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: []
我该如何解决这个问题？
答案 0 :(得分：5)
我多次遇到过这种行为。 Bundler可能不会卡住，而是正在探索可能的宝石版本的退化大型搜索空间。通过设置env var DEBUG_RESOLVER=1，您可以获得有关如何评估可能性的详细调试信息。阅读“How does Bundler bundle?”以了解算法和解析器跟踪的输出。
我通过从跟踪器中识别出一个宝石来解决这个问题，其中Bundler一直在回溯并重试许多不同的候选版本并将版本限制为大于某些最新版本。这通常有助于Bundler大幅减少搜索空间并快速完成其评估。当然，你添加的约束可能会产生与另一个gem的要求无法解决的冲突，在这种情况下，你可以逐步放宽你的约束，直到它兼容。
我有一个个人TODO回到这些退化的解决条件之一并将其转换为一组依赖关系和版本历史记录，这些都可以公开，因此我可以向Bundler开发者提交可重现的问题。 （我们的许多宝石都是我们公司的私人宝石。）源中的comment表示他们认为算法总是在合理的时间内完成，但根据经验，有些难以解决的问题无法通过< em>小时计算。
如果您的情况与我的情况相似，但完全依赖于公共宝石，那么如果您可以将问题gemfile和gemset公开，并将submit an issue发送给Bundler，那将是对社区的服务。深知道算法可以改善它。
Issue #2030表示可能存在解析器实际陷入无限循环的错误。如果您看到了这方面的证据，您可能希望将gem文件提交到该问题，特别是如果您的复制案例小于已提交的案例。