pod install和pod update – CocoaPods教程

上一章CocoaPods教程请查看：安装和使用CocoaPods

介绍

许多以CocoaPods为起点的人似乎认为pod install只在你第一次使用CocoaPods设置项目时使用，而pod update则是在之后使用。但事实并非如此。

本指南的目的是解释什么时候应该使用pod install，什么时候应该使用pod update。

提示：

• 使用pod install在你的项目中安装新的pod。即你已经有一个Podfile，那么先运行pod install，所以，即使你只是添加/删除pod到一个项目，也是已经使用了CocoaPods。
• 仅当你想要将pod更新到新版本时，才使用pod update [PODNAME]。

命令的详细解释

注意：install和update的命令实际上并不是特定于CocoaPods的。它受到了许多其他依赖项管理器的启发，比如bundler、RubyGems或composer，它们有类似的命令，行为和意图与本文档中描述的完全相同。

pod install

这将在你第一次为项目检索pod时使用，也将在你每次编辑Podfile以添加、更新或删除pod时使用。

• 每次运行pod install命令(以及下载和安装新pod)时，它都会将已安装的版本写入Podfile.lock文件中，该文件跟踪每个pod的安装版本并锁定这些版本。
• 当你运行pod install时，它只会解析Podfile.lock中未列出的pod的依赖项。
  • 对于Podfile.lock中列出的，它将下载Podfile.lock中列出的显式版本，而不尝试检查是否有更新的版本可用。
  • 对于Podfile.lock中没有列出的pod，它会搜索与Podfile中描述的匹配的版本(比如pod ‘MyPod’， ‘~>1.2’)

pod outdated

当你运行pod outdated时，CocoaPods会列出所有pod的更新版本，而不是Podfile.lock列出的版本(每个pod当前安装的版本)。这意味着如果你在这些pod上运行pod update PODNAME，它们将被更新——只要新版本仍然符合原来pod限制，如你的Podfile中设置的pod ‘MyPod’, ‘~>x.y’。

pod update

当你运行pod update PODNAME时，CocoaPods将尝试查找pod PODNAME的更新版本，而不考虑Podfile.lock中列出的版本。它将把pod更新到可能的最新版本(只要它符合你的Podfile中的版本限制)。

如果你运行pod update而没有pod名称，CocoaPods会将你的Podfile中列出的每个pod更新到可能的最新版本。

pod undate和pod install的使用

使用pod update PODNAME，你将只能更新特定的pod(检查是否存在新版本并相应地更新pod)。与pod install不同，pod install不会尝试更新已经安装的pod版本。

当你将pod添加到你的Podfile时，你应该运行pod install，而不是pod update—安装这个新的pod而不必冒险在相同的过程中更新现有的pod。

你将仅在希望更新特定pod(或所有pod)的版本时使用pod install。

提交Podfile.lock

提醒一下，即使你的策略是不将Pods文件夹提交到共享存储库中，你也应该始终提交并推送你的Podfile.lock文件。

否则，它将打破前面解释的pod install能够锁定你的pod安装版本的整个逻辑。

使用场景示例

下面是一个场景示例，演示在项目生命周期中可能遇到的各种用例。

阶段1：User1创建项目

user1创建了一个项目，并希望使用pod A、B、C，他们用这些pod创建一个Podfile，然后运行pod install。

这将安装pod A,B,C，我们假设说它们都在1.0.0版本中。

Podfile.lock将跟踪这一点，并注意到A、B和C都安装为1.0.0版本。

顺便说一句，因为那是他们第一次运行pod install，Pods.xcodeproj项目还不存在，该命令还将创建Pods.xcodeproj和.xcworkspace，但这是该命令的一个副作用，而不是它的主要作用。

阶段2：User1添加一个新的pod

稍后，user1希望将pod D添加到他们的Podfile中。

之后要运行pod install，即使执行pod install也不会影响pod B的版本，该项目将继续使用版本1.0.0——因为user1只想添加pod D，也不用担心意外更新pod B。

这就是有些会出错的地方，因为他们在这里使用pod install—可能认为这是“我想用新的pod更新我的项目？”—而不是使用pod install – 在项目中安装新的pod。

阶段3：User2加入项目

然后user2，他以前从未参与过这个项目，加入了这个团队。他们克隆存储库，然后使用pod install。

Podfile.lock的内容(应该提交到git repo上)将保证它们获得完全相同的pod，具有与user1使用的完全相同的版本。

即使pod C的1.2.0版本现在可用，user2将在1.0.0版本中获得pod C，因为这是在podfile.lock中注册的，pod C被Podfile.lock锁定到1.0.0版本。

阶段4：检查pod的新版本

稍后，user1希望检查pod是否有可用的更新。他们运行pod outdated，这将告诉他们pod B有一个新的1.1.0版本，而pod C有一个新的1.2.0版本发布。

user1决定更新pod B，但不更新pod C；因此，他们将运行pod update B，将B从版本1.0.0更新到版本1.1.0(并更新Podfile.lock），但是会在1.0.0版本中保留pod C(不会更新到1.2.0)。

在Podfile中使用确切的版本是不够的

有些人可能认为，通过在Podfile中指定pod的确切版本，比如pod ‘A’, ‘1.0.0’，就足以保证每个用户都拥有与团队中其他人相同的版本。

然后他们甚至可能使用pod update，即使只是添加一个新的pod，他们也会认为更新其他pod永远不会有风险，因为它们被固定到Podfile中的特定版本。

但实际上，这并不足以保证上面场景中的user1和user2将始终获得其所有pod的完全相同的版本。

一个典型的例子是，如果pod A依赖于在A中声明的pod A2。A.podspec作为依赖项’A2’， ‘~> 3.0’。在这种情况下，在你的Podfile中使用pod ‘A’， ‘1.0.0’确实会迫使user1和user2同时使用pod A的1.0.0版本，但是:

• user1可能会在3.4版中使用pod A2(因为那是当时A2的最新版本)
• 当user2稍后在加入项目时运行pod install时，他们可能会在3.5版中获得pod A2(因为A2的维护者可能同时发布了一个新版本)。

这就是为什么确保每个团队成员使用每个计算机上所有pod的相同版本的惟一方法是使用Podfile.lock并正确使用pod install和pod update。