pod install vs pod update

前言

针对最近同事无脑说pod update不好，写篇博客记录下，此文主要是翻译官网针对pod install与pod update进行比较

正文

介绍

许多人开始使用Cocoapods都认为pod install仅仅在第一次install pod库的时候使用，接下来会经常使用pod update，但是其实不然
    
这篇文章的目的是让你了解什么时候该用pod install什么时候该用pod update

TL;DR:
* 使用 pod install 去安装新的pod库，即使你已经有了Podfile并跑过了pod install ，所以即使刚刚在你的工程中增加或者删除pod库都可以
* Use pod update [PODNAME] only when you want to update pods to a newer version.
*仅当你想去更新某个pod库时到更新的版本时， 使用pod update [PODNAME]

详解

notes: 主要注意的是在Cocoapods中update与install与一般情景下的意义不一样，不是单纯的安装和更新

pod install

这个命令是用来获取新的pod库，但是每次你添加，删除，更新pod库而编辑Podfile也可以使用

• 每次运行pod install ,下载并安装新的pod库 ,它会记录已经安装库的版本，对于每个库来说Podfile.lock都会持续追踪已经安装库的版本

• 当你运行pod install, 它仅仅解决在Podfile.lock里面没有的pod库依赖

  • 对于在Podfile.lock中的pod库, 它会下载在Podfile.lock中已经列出来的版本, 不用去检查是否新的版本

  • 对于不在Podfile.lock中的库, 它会搜索在Podfile中指定的版本

pod outdated

当你使用pod outdate时, CocoaPods 会列出所以有比在Podfile.lock中更新的库。这意味着你可以对些库使用pod update PODNAME来更新到最新的版本, 只要这个新的版本符合podfile中设置的版本pod 'MyPod', '~>x.y'

pod update

当你运行pod update PODNAME, Cocoapods将会去找寻一个已经更新的版本的pod PODNAME, 不用去考虑在Podfile.lock中列出的版本 ,它可能将会更新最新的版本（只要你的Podfile没有版本限制）

用途

使用pod update PODNAME，你将仅仅能去更新某个指定pod （如果有新版本的话）,与pod install相对，pod install 并不会更新已安装的库，当你在Podfile中新增一个库，你应该使用pod install, 而不是pod update, 仅仅使用pod update去更新某个指定pod

提交你的Podfile.lock

提醒下，即使你的策略是不提交Pods文件到你的共享仓库，你应该经常commit & push你的Podfile.lock文件

不然，它将打乱pod installd的整个逻辑

接下来的场景就比较易懂了，就不翻译了

Stage 1: User1 creates the project

user1 creates a project and wants to use pods A,B,C. They create a Podfile with those pods, and run pod install.

This will install pods A,B,C, which we’ll say are all in version 1.0.0.

The Podfile.lock will keep track of that and note that A,B and C are each installed as version 1.0.0.

Incidentally, because that’s the first time they run pod install and the Pods.xcodeproj project doesn’t exist yet, the command will also create the Pods.xcodeproj and the .xcworkspace, but that’s a side effect of the command, not its primary role.

Stage 2: User1 adds a new pod

Later, user1 wants to add a pod D into their Podfile.

They should thus run pod install afterwards, so that even if the maintener of pod B released a version 1.1.0 of their pod since the first execution of pod install, the project will keep using version 1.0.0 — because user1 only wants to add pod D, without risking an unexpected update to pod B.

That’s where some people get it wrong, because they use pod update here — probably thinking this as “I want to update my project with new pods”? — instead of using pod install — to install new pods in the project.

Stage 3: User2 joins the project

Then user2, who never worked on the project before, joins the team. They clone the repository then use pod install.

The contents of Podfile.lock (which should be committed onto the git repo) will guarantee they will get the exact same pods, with the exact same versions that user1 was using.

Even if a version 1.2.0 of pod C is now available, user2 will get the pod C in version 1.0.0. Because that’s what is registered in Podfile.lock. pod C is locked to version 1.0.0 by the Podfile.lock (hence the name of this file).

Stage 4: Checking for new versions of a pod

Later, user1 wants to check if any updates are available for the pods. They run pod outdated which will tell them that pod B have a new 1.1.0 version, and pod C have a new 1.2.0 version released.

user1 decides they want to update pod B, but not pod C; so they will run pod update B which will update B from version 1.0.0 to version 1.1.0 (and update the Podfile.lock accordingly) but will keep pod C in version 1.0.0 (and won’t update it to 1.2.0).

Using exact versions in the Podfile is not enough
Some might think that by specifying exact versions of their pods in their Podfile, like pod ‘A’, ‘1.0.0’, is enough to guarantee that every user will have the same version as other people on the team.

Then they might even use pod update, even when just adding a new pod, thinking it would never risk to update other pods because they are fixed to a specific version in the Podfile.

But in fact, that is not enough to guarantee that user1 and user2 in our above scenario will always get the exact same version of all their pods.

One typical example is if the pod A has a dependency on pod A2 — declared in A.podspec as dependency ‘A2’, ‘~> 3.0’. In such case, using pod ‘A’, ‘1.0.0’ in your Podfile will indeed force user1 and user2 to both always use version 1.0.0 of the pod A, but:

user1 might end up with pod A2 in version 3.4 (because that was A2’s latest version at that time)
while when user2 runs pod install when joining the project later, they might get pod A2 in version 3.5 (because the maintainer of A2 might have released a new version in the meantime).
That’s why the only way to ensure every team member work with the same versions of all the pod on each’s computer is to use the Podfile.lock and properly use pod install vs. pod update.