当我们的项目比较大、使用的第三方的库多了以后,执行pod update命令偶尔就会出现类似这样的错误:

[!] Unable to satisfy the following requirements:
\- 'A (=2.0)' required by 'Podfile'
\- 'A' required by 'B'
\- 'A (~> 1.4)' required by 'C (1.6)'

这个错误信息很简单有很让人费解,我们仅仅知道 pod 无法满足我们的需求,但是是什么需求?没有说啊ಥ_ಥ.

逗我?

其实事情的真相是各种不同的库以及 podfile 本身对于某一个库的版本要求出现了冲突,导致 pod 不知道应该做些什么,因此启只好无奈的把这些冲突的地方都写出来,让开发者进行处理。

在开头的那段错误 log 想要表达的意思是:开发者在 Podfile 中要求 A 是 2.0 版本,而 B 要求 A 是最新的版本,最要命的 C 竟然要求 A 是大于1.4但是小于2.0的版本,这里和最开始 podfile 的版本要求起了冲突,导致pod 无法进行正常的库管理。

那么在这种情况下我们可以首先尝试把 C 更新到当前最新的版本,因为很有可能 C 库的开发者已经更改了对于 A 的依赖的版本规则;如果不行,我们要么得去 clone 出来一个自己的 C 然后去修改 podspec,要么就是换用其他的和 C 类似的库来解决版本冲突问题,要么就是更改 podfile 以及回退 B 的版本,让A 的某一个版本同时存在于 Podile 、B、C 的版本要求的交集中。

另外,在 pod 的0.35版本中已经做了一些对于冲突解决的优化,举个例子:

pod ' A' # Version 2.0.0 activates AFNetworking with: >= 2.0.0 && < 3.0.0
pod 'B' # Version 2.1.0 activates AFNetworking with: >= 2.2.0 && < 3.0.0
pod 'C' # Version 0.1.2 activates AFNetworking with: >= 1.3.0 && < 2.0.0

这样的版本要求在0.35之前是会报出文章最开头的那个错误的,但是0.35以后,pod 会把 A、B回退到一个要求 AF 的版本范围为 1.x 到 2.x 的版本。

参考:Automatic Conflict Resolution


Forelax
666 声望28 粉丝

不断探索更大的世界