【IOS学习】pod install vs. pod update

介绍

很多人以为 ‘pod install’只是在初次创建项目的时候使用，而对已存在cocoapods的项目则使用命令pod update，但事实并非如此。

这篇文档将解释何时使用 pod install， 何时使用 pod update。

• 使用 pod install 为项目添加新的类库（pods），即使项目中已经存在 Podfile或者已经使用过 pod install 命令。当你需要为项目添加或者移除第三方库的时候，均使用 pod install。

• 只有在需要更新第三方库版本的时候，才使用 pod update ［PODNAME］

命令详解

注意：文中 install 和 update 的释义并非仅在 CocoaPads 中适用，在其他依赖管理工具中（bundler， RubyGems，composer）中同样适用，这两条命令在各个工具中具有同样的行为和意图。

pod install

当第一次为项目导入第三方库的时候使用此命令，同时，以后每次编辑Podfile为项目添加、删除、更新类库的时候，均使用此命令。

• 每次执行此命令，会下载并安装新的类库，同时将每个类库的名称和版本记录在 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中的有可用更新的类库（相比于当前安装的类库版本）。这意味着只要新版本符合Podfile中设置的格式（pod ‘MyPod’,’~>x.y’）,就可以使用 pod update PODNAME 命令来更新这些类。

pod update

当你使用 pod update PODNAME，CocoaPods 将会查找 PODNAME 类的最新版本，此时不会考虑 Podfile.lock 中记录的版本。如果存在于Podfile中对应的新版本，就会将此类库更新到最新版本。

如果未指明PODNAME而直接使用 pod update 命令，CocoaPods将会更新 Podfile中所有类库。

Intended usage

使用 pod update PODNAME，将会更新指定的类库（如果存在新版本则更新）。相反， pod install并不会更新已安装的类库。

当你在Podfile中添加了新的类库时，应当使用 pod install 而不是 pod update，pod update在添加新的类库的同时，也可能更新其他类库。

只有需要更新指定类库（或所有类库）时，才能使用 pod update。

Commit your Podfile

请注意，虽然你不回commit Pods文件夹，但需要commit & push Podfile.lock文件。

Otherwise, it would break the whole logic explained above about pod install being able to lock the installed versions of your pods.

Podfile.lock：当你执行 pod install 之后，除了 Podfile 外，CocoaPods 还会生成一个名为 Podfile.lock 的文件, Podfile.lock 应该加入到版本控制里面，不应该把这个文件加入到 .gitignore 中。因为 Podfile.lock 会锁定当前各依赖库的版本，之后如果多次执行 pod install 不会更改版本，要 pod update 才会改 Podfile.lock 了。这样多人协作的时候，可以防止第三方库升级时造成大家各自的第三方库版本不一致。

此段出处：CocoaPods你想要的都在这

使用场景案例

此节为模拟使用场景，将说明整个项目周期可能遇到的各种情况。

场景1: 程序员甲创建了项目

甲创建了项目文件并需要向项目中导入A, B, C三个类库。 他根据类库创建了Podfile文件，然后执行 pod install。

就这样安装了A,B,C三个类库，同时它们的版本都为1.0.0 。同时 Podfile.lock 文件中记录下了它们的版本信息。

顺便提一下：因为这是他们第一次运行 pod install命令，而且还没有 Pods.xcodeproj 项目文件。这条命令同时会创建Pods.xcodeproj 和 .xcworkspace， 虽然这也是pod install 的附带效果，但并不是主角。

场景2:甲添加了一个新的库

没过多久，甲想将类库D添加到Podfile中。

那么此时他们在修改Podfile之后需要使用pod install 命令，这样即使类库B的维护者发布了1.1.0的新版本，甲仍能保证项目中B是1.0.0版——因为甲只想添加类库D，并不想意外的更新某个类库。

很多人在这个场景犯错，他们经常使用 pod update命令——大概在想“我需要用update来更新我的项目吧”。正确的选择应该使用pod install 来安装新的类库。

场景3:程序员乙加入到项目中

程序员乙刚刚加入到这个项目中，他clone repository 之后使用pod install安装第三发类库命令。

项目中的Podfile.lock将提供类库的版本信息，保证甲和乙使用相同版本的类库，不会带来大家版本不一致的问题。

即使类库C已经更新到版本1.2.0，但乙安装的C的版本仍是1.0.0 。因为Podfile.lock 已经将C的版本锁定为1.0.0了。

场景4:检查类库更新版本

没过多久，甲想检查一下类库是否有新版本。于是他使用 pod outdated 命令，发现类库B有1.1.0版本，类库C有1.2.0版本。

但甲只想更新B，不想更新C；于是他运行 pod update B 将B更新到1.1.0版，这个命令同时更新了Podfile.lock 文件中B的纪录。此时C仍为1.0.0版，不会更新。

在Podfile中指定类库版本还不够

有些人可能认为只要在 Podfile 中指定版本信息就好了，就像 pod ‘A’, ‘1.0.0’ ，足够保证团队中每个人都能使用相同版本的类库了，何须像上面那么麻烦？

之后向项目添加其他类库时，他们可能会使用 pod update， 心想”我已经在 Podfile 中指定了版本信息了，不用担心更新其他类库“。

但事实并非如此，这样做并不能保证上面情景中，甲乙始终使用相同的类库。

据一个典型的例子，类库A依赖于声明在 A.podspec 中的类库A2（dependence ‘A2’,’~>3.0’）。这种情况,在 Podfile 中写入 pod ‘A’, ‘1.0.0’ 的确能保证甲乙同时使用1.0.0版本的A，但是：

• 甲结束编辑项目的时候，A2的版本为3.4（因为这是当时最新版本）

• 后来，乙加入项目，当他使用 pod install 的时候，可能得到A2的版本是3.5（因为A2的维护者可能在甲乙交界期间发布了新版本）

为了保证团队中每个成员都使用相同版本的类库，一定要commit&push Podfile.lock,同时正确区别使用pod install 和pod update。