CocoaPods 系列（二）—— pod install vs

介绍

很多人使用 CocoaPods 的时候可能会以为第一次是用 pod install 安装配置工程，之后都是用pod update ，但其实不是这样。

这篇文章的目的是为了解释 pod install 和 pod update正确的使用时机。

TL;DR:

• 如果你是第一次安装 pods ，或者你在 Podfile 中新增/移除了 pods， 使用 pod install 命令安装 pods 。
• 在更新新版本的 pods 时，使用 pod update [PODNAME] 。

命令详情

小提示：使用install 和 update 的词汇并不是 CocoaPods 想出来的。灵感来源于其他语言的依赖管理，比如 bundler， RubyGems，composer 等，它们跟 CocoaPods 有着很多相似的命令，意图也相同。

pod install

在第一次安装 pods 的使用该命令，但也可以在每次往 Podfile中新增，修改 ，移除 pods 的时候使用。

• 每次执行 pod install 命令 —— 下载并安装新的 pods —— 根据 Podflie.lock 文件的版本来安装对应的 pod。
• 当执行 pod install 时，只解决没有在 Podfile.lock 里列出的 pods。
  • 如果在 Podfile.lock 列表中，会先下载 Podfile.lock 中显示指定的版本，而不会试图安装新版本。
  • 如果不在 Podfile.lock 列表中，会搜索在 Podfile 文件列表中指定的版本（就像 pod ‘MyPod’, ‘~>1.2’）

pod outdated

当执行 pod outdated, CocoaPods 会列出 Podfile.lock 中所有新版本的 pods。这意味着如果你执行 pod update PODNAME，这些 pods 会被更新到 Podfile 文件里面所指定的能够升级的最高版本，形如：pod 'MyPod', '~>x.y’。

Podfile 版本约束规则可以参考这里。

pod update

当执行 pod update PODNAME时，Cocoapods 会查找 PODNAME 新的版本，忽略 Podfile.lock 中锁定的版本号。将 pods 升级到最高版本，不过仍会受到 Podfile 中指定的版本约束。

如果执行 pod update 没有指定名字， CocoaPods 会更新Podfile 列表中所有的 pods。

根据意图使用

pod update PODNAME 会更新指定的 pod，相对的 pod install 不会更新已经安装的 pods 版本。

当新增 pod 到 Podfile，你应该使用 pod install， 而不是 pod update 来安装新版本的 pod ，避免在这个过程中更新已经存在的 pods。

如果你想要更新新版本 pods 再使用 pod update 命令。

提交 Podfile.lock 文件

作为提醒，如果你没有提交 Pods 文件目录到 git，你必须提交并推送 Podfile.lock 文件。

否则，可能会造成团队之间执行 pod install安装的 pods 版本不一致。

案例

下面介绍一些在实际工程项目中可能会遇到的问题。

阶段一：用户 1 创建工程

用户 1 创建了一个新的工程并想要使用 A, B,C三个 pods。他创建Podfile 文件，加入这三个 pods，并执行 pod install。

这样就成功安装了 A, B, C三个 pods，假设它们的版本都是 1.0.0。

Podfile.lock 会跟踪并记录 A, B, C 的版本为 1.0.0。

因为这是我们第一次执行 pod install，.xcodeproj 工程将不再存在。取而代之的是 .xcworkspace 以及 Pods.xcodeproj，但这并不会影响主工程的功能。

阶段二：添加一个 pod

此后，如果用户 1 想要新增 pod D 到 Podfile 文件。

他必须执行 pod install，即使现在 pod B 发布了新版本 1.1.0，工程仍然会使用 1.0.0 的版本。因为用户 1 只是想添加 pod D并不希望更新其它的 pods。

这里有些用户可能会误用 pod update，这是不对的。

阶段三：用户 2 加入工程

接着用户 2 需要参与工程开发，他是新加入的，先克隆了工程并执行 pod install。

Podfile.lock 文件(已被提交到版本控制)会保证新用户安装的 pods 版本，同用户 1 的一致。

即使 pod C 此时有新版本 1.2.0可用，用户 2 安装的仍旧是 1.0.0版本。因为 C 已经被 Podfile.lock 文件锁定在 1.0.0 版本了。

阶段四：检查 pod 新版本

之后，用户 1 想要检查一下 pods 是否有新版本可用，他执行 pod outdated 这将会告诉他 B 发布了 1.1.0, C 发布了 1.2.0 的新版本。

用户 1 决定更新 pod B，但是不想更新 pod C，所以他执行 pod update B 将 B 从 1.0.0 版本更新到 1.1.0 版本（会同时更新 Podfile.lock 文件）并保持 pod C 的版 本还是 1.0.0。

为 Podfile 文件指定版本号的缺陷

有人可能会认为只要在 Podfile 文件中指定 pods 的版本，就可以保证团队之间保持相同版本的 pods，比如 pod ‘A’， ‘1.0.0’

在加入新 pod 的时候，即使执行 pod update,也不会有升级其它 pods 的风险，因为它们的版本在 Podfile 中指定死了。

但实际上，上述场景并不能保证 用户1 和 用户2 所有 pods 的版本都一致。

举个典型的例子，加入 pod A 在 A.podspec (关于 podspec 的说明请查看 CocoaPods 制作专题)文件中指定依赖为 ’A2’, ‘~> 3.0’，这种情况下，在 Podfile 中使用 pod 'A', ‘1.0.0’ 这的确会保证用户 1 和 用户 2 使用的 pod A 是 1.0.0 版本的，但是：

• 用户 1 当时安装的 A2 是 3.4 版本的；
• 当用户 2 加入并执行 pod install 的时候，A2 可能有了 3.5 版本，就会导致他安装的是最新版本的。

所以，这就是为什么需要团队之间协作将 Podfile.lock 提交到版本控制，并正确的区分 pod install 和 pod update的重要性。

原文