介紹
很多人使用 CocoaPods 的時(shí)候可能會(huì)以為第一次是用 pod install 安裝配置工程,之后都是用pod update ,但其實(shí)不是這樣。
這篇文章的目的是為了解釋 pod install 和 pod update正確的使用時(shí)機(jī)。
TL;DR:
- 如果你是第一次安裝 pods ,或者你在 Podfile 中新增/移除了 pods, 使用
pod install命令安裝 pods 。 - 在更新新版本的 pods 時(shí),使用
pod update [PODNAME]。
命令詳情
小提示:使用
install和update的詞匯并不是 CocoaPods 想出來(lái)的。靈感來(lái)源于其他語(yǔ)言的依賴(lài)管理,比如 bundler, RubyGems,composer 等,它們跟 CocoaPods 有著很多相似的命令,意圖也相同。
pod install
在第一次安裝 pods 的使用該命令,但也可以在每次往 Podfile中新增,修改 ,移除 pods 的時(shí)候使用。
- 每次執(zhí)行
pod install命令 —— 下載并安裝新的 pods —— 根據(jù)Podflie.lock文件的版本來(lái)安裝對(duì)應(yīng)的 pod。 - 當(dāng)執(zhí)行
pod install時(shí),只解決沒(méi)有在Podfile.lock里列出的 pods。- 如果在
Podfile.lock列表中,會(huì)先下載Podfile.lock中顯示指定的版本,而不會(huì)試圖安裝新版本。 - 如果不在
Podfile.lock列表中,會(huì)搜索在Podfile文件列表中指定的版本(就像pod ‘MyPod’, ‘~>1.2’)
- 如果在
pod outdated
當(dāng)執(zhí)行 pod outdated, CocoaPods 會(huì)列出 Podfile.lock 中所有新版本的 pods。這意味著如果你執(zhí)行 pod update PODNAME,這些 pods 會(huì)被更新到 Podfile 文件里面所指定的能夠升級(jí)的最高版本,形如:pod 'MyPod', '~>x.y’。
Podfile 版本約束規(guī)則可以參考這里。
pod update
當(dāng)執(zhí)行 pod update PODNAME時(shí),Cocoapods 會(huì)查找 PODNAME 新的版本,忽略 Podfile.lock 中鎖定的版本號(hào)。將 pods 升級(jí)到最高版本,不過(guò)仍會(huì)受到 Podfile 中指定的版本約束。
如果執(zhí)行 pod update 沒(méi)有指定名字, CocoaPods 會(huì)更新Podfile 列表中所有的 pods。
根據(jù)意圖使用
pod update PODNAME 會(huì)更新指定的 pod,相對(duì)的 pod install 不會(huì)更新已經(jīng)安裝的 pods 版本。
當(dāng)新增 pod 到 Podfile,你應(yīng)該使用 pod install, 而不是 pod update 來(lái)安裝新版本的 pod ,避免在這個(gè)過(guò)程中更新已經(jīng)存在的 pods。
如果你想要更新新版本 pods 再使用 pod update 命令。
提交 Podfile.lock 文件
作為提醒,如果你沒(méi)有提交 Pods 文件目錄到 git,你必須提交并推送 Podfile.lock 文件。
否則,可能會(huì)造成團(tuán)隊(duì)之間執(zhí)行 pod install安裝的 pods 版本不一致。
案例
下面介紹一些在實(shí)際工程項(xiàng)目中可能會(huì)遇到的問(wèn)題。
階段一:用戶(hù) 1 創(chuàng)建工程
用戶(hù) 1 創(chuàng)建了一個(gè)新的工程并想要使用 A, B,C三個(gè) pods。他創(chuàng)建Podfile 文件,加入這三個(gè) pods,并執(zhí)行 pod install。
這樣就成功安裝了 A, B, C三個(gè) pods,假設(shè)它們的版本都是 1.0.0。
Podfile.lock 會(huì)跟蹤并記錄 A, B, C 的版本為 1.0.0。
因?yàn)檫@是我們第一次執(zhí)行
pod install,.xcodeproj工程將不再存在。取而代之的是.xcworkspace以及Pods.xcodeproj,但這并不會(huì)影響主工程的功能。
階段二:添加一個(gè) pod
此后,如果用戶(hù) 1 想要新增 pod D 到 Podfile 文件。
他必須執(zhí)行 pod install,即使現(xiàn)在 pod B 發(fā)布了新版本 1.1.0,工程仍然會(huì)使用 1.0.0 的版本。因?yàn)橛脩?hù) 1 只是想添加 pod D并不希望更新其它的 pods。
這里有些用戶(hù)可能會(huì)誤用
pod update,這是不對(duì)的。
階段三:用戶(hù) 2 加入工程
接著用戶(hù) 2 需要參與工程開(kāi)發(fā),他是新加入的,先克隆了工程并執(zhí)行 pod install。
Podfile.lock 文件(已被提交到版本控制)會(huì)保證新用戶(hù)安裝的 pods 版本,同用戶(hù) 1 的一致。
即使 pod C 此時(shí)有新版本 1.2.0可用,用戶(hù) 2 安裝的仍舊是 1.0.0版本。因?yàn)?C 已經(jīng)被 Podfile.lock 文件鎖定在 1.0.0 版本了。
階段四:檢查 pod 新版本
之后,用戶(hù) 1 想要檢查一下 pods 是否有新版本可用,他執(zhí)行 pod outdated 這將會(huì)告訴他 B 發(fā)布了 1.1.0, C 發(fā)布了 1.2.0 的新版本。
用戶(hù) 1 決定更新 pod B,但是不想更新 pod C,所以他執(zhí)行 pod update B 將 B 從 1.0.0 版本更新到 1.1.0 版本(會(huì)同時(shí)更新 Podfile.lock 文件)并保持 pod C 的版 本還是 1.0.0。
為 Podfile 文件指定版本號(hào)的缺陷
有人可能會(huì)認(rèn)為只要在 Podfile 文件中指定 pods 的版本,就可以保證團(tuán)隊(duì)之間保持相同版本的 pods,比如 pod ‘A’, ‘1.0.0’
在加入新 pod 的時(shí)候,即使執(zhí)行 pod update,也不會(huì)有升級(jí)其它 pods 的風(fēng)險(xiǎn),因?yàn)樗鼈兊陌姹驹?Podfile 中指定死了。
但實(shí)際上,上述場(chǎng)景并不能保證 用戶(hù)1 和 用戶(hù)2 所有 pods 的版本都一致。
舉個(gè)典型的例子,加入 pod A 在 A.podspec (關(guān)于 podspec 的說(shuō)明請(qǐng)查看 CocoaPods 制作專(zhuān)題)文件中指定依賴(lài)為 ’A2’, ‘~> 3.0’,這種情況下,在 Podfile 中使用 pod 'A', ‘1.0.0’ 這的確會(huì)保證用戶(hù) 1 和 用戶(hù) 2 使用的 pod A 是 1.0.0 版本的,但是:
- 用戶(hù) 1 當(dāng)時(shí)安裝的 A2 是
3.4版本的; - 當(dāng)用戶(hù) 2 加入并執(zhí)行
pod install的時(shí)候,A2可能有了3.5版本,就會(huì)導(dǎo)致他安裝的是最新版本的。
所以,這就是為什么需要團(tuán)隊(duì)之間協(xié)作將 Podfile.lock 提交到版本控制,并正確的區(qū)分 pod install 和 pod update的重要性。