个性化阅读
专注于IT技术分析

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。

赞(0)
未经允许不得转载:srcmini » pod install和pod update – CocoaPods教程

评论 抢沙发

评论前必须登录!