Bundler在安装或更新宝石时卡住了

Question

我最近试图运行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: []

我该如何解决这个问题？

Answer 1

我好几次遇到过这种行为.Bundler可能不会卡住,而是正在探索可能的宝石版本的退化大型搜索空间.您可以通过设置env var获取有关如何评估可能性的详细调试信息DEBUG_RESOLVER=1.阅读" Bundler如何捆绑？ "以了解解析器跟踪的算法和输出.

我工作围绕这一问题通过识别从用于捆扎机是一贯回溯跟踪和重试许多不同的候选版本的宝石和限制的版本比一些最新版本更高.这通常有助于Bundler大幅减少搜索空间并快速完成其评估.当然,您添加的约束可能会产生与另一个gem的要求无法解决的冲突,在这种情况下,您可以逐步放宽约束,直到它兼容.

我有一个个人TODO回到这些退化的解决条件之一并将其转换为一组依赖关系和版本历史,这些都可以公开,所以我可以向Bundler开发者提交可重现的问题.(我们的许多宝石都是私有公司.)这个评论在源表示,他们认为该算法始终处于合理的时间内完成,但经验上还有一些具有不能与解决方案有效疑难案件小时计算.

如果您的情况与我的情况相似,但完全依赖于公共宝石,那么如果您可以将问题gemfile和gemset公开并向 Bundler 提交问题,那么它将是对社区的服务,因此深入了解算法的人可以改进它.

问题#2030表示可能存在解析器实际陷入无限循环的错误.如果您看到了这方面的证据,您可能希望将gem文件提交到该问题,特别是如果您的复制案例小于已提交的案例.