pod install和pod update的区别以及各自使用场景

简介

大多数人使用CocoaPods的时候都会想当然的以为pod install仅仅在第一次初始化项目的时候使用,pod update在接下来的更新中使用,事情并非如此。

接下来的文章将向你介绍合适使用pod install 何时使用 pod update.

  • pod install用在第一次在你的项目中安装pods的时候,即使已经存在Podfile文件或者之前进行过pod install.
  • pod update 一般在你想要更新pods到一个新的版本的时候使用。

命令的详细说明

注意:install 和 update并不仅仅在CocoaPods中使用,它其实是受到很对以来管理器的启发(比如: bundler, RubyGems or composer),同样具有类似的命令。

pod install

这个命令常常用在你第一次你为项目添加pods时使用,当然在你编辑了你的pod文件用来添加、更新或者删除依赖时也可使用。

  • 每次当pod install 命令运行,并下载安装新的pods的时候,他会在Podfile.lock中为每个pod写入它安装的版本。此文件跟踪每一个已安装的版本,并且锁定这些版本。
  • 当运行pod install 的时候它仅仅解析那些Podfile.lock中位列出的依赖关系。
    • 对于Podfile.lock中列出的pods,它仅仅会下载指明的版本,不会去检查是否有新版本可用。
  • 对于Podfile.lock中未列出的pods,他会搜索与Podfile中内容相匹配的版本 (例如 pod 'MyPod', '~>1.2')。

pod update

当运行pod update PODNAME时,CocoaPods将尝试查找PODNAME的更新版本,而不考虑Podfile.lock中列出的版本。 它会将pod更新为可能的最新版本(只要它与Podfile中的版本限制相匹配)。

如果运行pod更新没有pod名称,CocoaPods将更新您Podfile中列出的每个pod到最新的版本。

pod outdated

当运行pod过时时,CocoaPods将列出所有具有比Podfile.lock中列出的版本更高版本的pod(当前为每个pod安装的版本)。 这意味着如果您在这些pod上运行pod update PODNAME,它们将被更新 - 只要新版本仍然匹配像您在Podfile中设置的“MyPod”,“〜> x.y”这样的限制。

预期使用

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

当您将Pod添加到Podfile时,您应该运行pod install而不是pod update - 来安装此新的pod,而无需在同一个进程中更新现有的pod。

只有当您要更新特定pod(或所有pods)的版本时,才会使用pod update。

提交你的Podfile.lock

作为提醒,即使您的策略不是将Pods文件夹提交到共享存储库,您应该始终提交并推送Podfile.lock文件。

否则,它将破坏上面解释的关于pod安装能够锁定您的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

  • 因此,接下来他们应该运行pod install,即使pod B的维护者从第一次执行pod install以来发布了它们的pod的1.1.0版本,该项目将继续使用1.0.0版本 - 因为user1只想添加 pod D,而不会有冒险更新到pod B。

这也许是大部分人错误使用pod update的原因(他们也许认为我仅仅是想跟新一个pod,而不是重新在项目中安装一个pod)。

  • 阶段3:User2加入项目

  • 然后,user2(从来没有工作过的项目,加入团队)。 他克隆存储库,然后使用pod install。

  • Podfile.lock(应该提交到git repo)的内容将确保他们将获得完全相同的pods,与user1使用完全相同的版本。

即使版本1.2.0的pod C现在可用,user2将获得版本1.0.0中的pod C。 因为这是在Podfile.lock中注册的。 pod C由Podfile.lock(因此是这个文件的名称)锁定到版本1.0.0。

  • 阶段4:检查pod的新版本

  • 接下来,当user1想要检查是否有可用的pod的更新时。 他们运行pod update,这将告诉他们,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),但将保持pod C在1.0.0版本(不会更新到1.2。 0)。

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

  • 有些人可能认为通过在Podfile中指定其pod的精确版本(例如pod'A','1.0.0')足以保证每个用户都具有与团队中其他人相同的版本。
  • 然后,他们认为可以使用pod更新,即使只是添加一个新的pod,认为它永远不会存在更新其他pod的风险(因为它们固定在Podfile中)。
  • 但实际上,这不足以保证user1和user2在我们上面的场景中将始终获得所有其pod的完全相同的版本。
  • 一个典型的例子是如果pod A具有对pod A2的依赖性 - 在A.podspec中声明为依赖“A2”,“〜> 3.0”。 在这种情况下,使用pod'A','1.0.0'在您的Podfile将确实强制user1和user2都使用1.0版本的pod A,但是:
  • user1可能最终获取到3.4版本的pod A2(因为那是A2的最新版本)
  • 而当用户2在稍后加入项目时运行pod安装时,他可能获取到3.5版本的pod A2(因为A2的维护者可能已经同时释放了新版本)。

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

推荐阅读更多精彩内容