iOS进阶 - pod install 与 pod update 读这一篇就够了

前言

在使用CocoaPods时，难免会混淆 pod install 和 pod update 的用法，于是在官网找到了相应的说明文章，并决定翻译过来，供大家学习。

以下内容来自:pod install vs. pod update翻译。

介绍

很多人使用CocoaPods时往往认为pod install只是在首次配置项目的时候使用的，而pod update是稍后更新库的时候使用的。但是事实并非如此。

这篇文章的目的是阐述清楚什么时候使用pod install命令，什么时候使用pod update命令。

综述：

• 使用 pod install 在你的项目中安装新的库，即使你已经有了 Podfile 文件并且运行过 pod install 命令，或者你已经有添加、删除过库。
• 使用 pod update [PODNAME] 仅仅是在你想更新库版本的时候。

命令的详细细节：

pod install:

• 该命令是你第一次在项目中获取库的时候使用，并且在每次对 Podfile 文件编辑的时候（添加、更新、删除）使用。
• 每一次运行 pod install 命令后，都会去下载安装新的库，并且会修改 Podfile.lock文件中记录的库的版本。Podfile.lock文件只是用来追踪和锁定这些库的版本。
• 运行 pod install 后，它仅仅只能解决 Podfile.lock中没有列出来的依赖关系。
• 在 Podfile.lock中列出的那些库，也仅仅只是去下载 Podfile.lock中指定的版本，并不会去检查最新的版本。
• 没有在 Podfile.lock中列出的那些库，会去检索 Podfile 中指定的版本，比如 pod 'myPod', '~>1.2'。

pod outdated:

• 当你使用 pod outdated 时，CocoaPods 会罗列出所有在 Podfile.lock中记录的有新版本的库，意思是，如果你进行了 pod update PODNAME 操作，只要这些库符合 Podfile.lock中的版本限制（如 pod MyPod, '~>x.y'），那么它就会更新。

pod update

• 当你运行了 pod update PODNAME 命令，CocoaPods 将不会考虑 Podfile.lock中列出的版本，而直接去查找该库的新版本。它将更新到这个库尽可能新的版本，只要符合 Podfile 中的版本限制要求。
• 如果使用 pod update 命令不带库名参数，CocoaPods 将会去更新 Podfile 中每一个库的尽可能新的版本。

正确的用法：

1. 使用 pod update PODNAME 可以去更新一个库的 指定版本（检查相应的库是否存在更新的版本，并且更新），相对应的，使用 pod install 将不会更新那些已经下载安装了的库。
2. 当你在 Podfile 中添加一个新的库时，你应该使用 pod install 命令， 而不是 pod update ，这样安装了新增的库，也不会重复安装已经存在的库。
3. 使用 pod update 仅仅只是去更新指定库的版本（或者全部库）。

提交你的Podfile.lock文件:

提醒一下，即使你一向不 commit 你的库文件到你的共享仓库，你也应该总是 commit & push 到你的 Podfile.lock文件中。
否则，就会破坏掉 pod install 的整个设计逻辑，造成 Podfile.lock文件无法锁定你已经安装的库。

场景应用：

例1：用户1创建了一个项目

用户1创建了一个工程，并且想使用A、B、C这三个库，所以他就创建了一个含有这个三个库的Podfile文件，并且运行pod intall命令。

这样就会安装了A、B、C三个库到这个工程里面，假设我们的版本都为1.0.0。

因此Podfile.lock将会跟踪并记录A、B、C这三个库以及它们的版本号1.0.0。

顺便说一下：因为第一次运行pod install，并且Pods.xcodeproj工程文件还不存在，所以这个命令会同时创建Pods.xcodeproj以及.xcworkspace工程文件，这只是这个命令的一个副作用，但不是主要目的。

例2：用户1添加了一个新库

其后，用户1添加了一个库D到Podfile文件中。

然后他就运行pod install命令了。因此即使库B的开发者发布了B的一个新版本1.1.0。但只要是在第一次执行pod install之后发布的新的版本，那么B的版本使用的仍然是1.0.0。因为用户1只是希望添加一个新库D，不希望更新库B。

这就是很多人容易出错的地方，因为他们在这里使用了pod update，而不是pod install，可能是想着“我要更新一下我工程中的库”。

例3：用户2加入到工程中

用户2是一个之前没有参与到这个工程的人，稍后加入到项目中。他使用pod install命令克隆了代码仓库。

如果Podfile.lock被提交到git仓库中，那么Podfile.lock的内容就会确保用户1和用户2会得到完全一样的库。

即使库C已经有了到了1.2.0版本，用户2使用的库C仍然是1.0.0版本，因为库C已经在Podfile.lock里面注册过了，库C的1.0.0版本已经在Podfile.lock中被锁住了。

例4：检查某个库的新版本

之后，用户1想检查pods里面是否有可更新的库时，他执行了 pod outdated，这个命令将会罗列出来：库B有了新版本1.1.0，库C有了新版本1.2.0。

用户1决定更新库B，但不更新库C，所以执行pod update B，这样就把库B从1.0.0更新到1.1.0（同时更新Podfile.lock中相应的库B的版本记录），此时，库C仍然是1.0.0版本，不会被更新到1.2.0。

在Podfile中使用明确的版本还不够

有些人可能认为在Podfile中指定某个库的版本已经足以保证所有项目团队中的人都会使用完全一样的版本，比如：pod 'A', '1.0.0' 。

然后，他们可能认为此时如果添加一个新库的时候，我使用pod update并不会去更新其它的库，因为其它的库已经被限定了固定的版本号。

但事实上，在以上场景中，这不足以保证用户1和用户2用到的库版本完全一样。

一个典型的例子是，如果库A对A2有一个依赖（比如声明在A.podspec中：dependency 'A2', '~> 3.0'），这样的话，在你的Podfile中使用 pod 'A', '1.0.0'将会让用户1和用户2都使用同样版本的库A（1.0.0）。

• 但是，用户1最后可能使用的是版本为3.4的库A2（因为3.4是当时用户1使用的最新版本）。

• 用户2稍后加入到项目中，使用pod install 安装库，得到的库A2版本可能是3.5（假设A2的开发者刚刚发布了A2的新版本3.5）。

这就是为什么使用Podfile.lock这一个方式来保证参与项目的每个开发者的电脑中都使用相同版本的库，并且合理的使用pod install和 pod update。