前言
在使用CocoaPods時,難免會混淆pod install
和 pod update
的用法,于是在官網找到了相應的說明文章,并決定翻譯過來,供大家學習。
以下內容來自:pod install vs. pod update翻譯。
正文
介紹
很多人使用CocoaPods時往往認為pod install
只是在首次配置項目的時候使用的,而pod update
是稍后更新庫的時候使用的。但是事實并非如此。
這篇文章的目的是闡述清楚什么時候使用pod install
命令,什么時候使用pod update
命令。
綜述:
使用
pod install
在你的項目中安裝新的庫,即使你已經有了Podfile
文件并且運行過pod install
命令,或者你已經有添加、刪除過庫。使用
pod update [PODNAME]
僅僅是在你想更新庫版本的時候。
命令的詳細細節:
pod install:
該命令是在你第一次在項目中獲取庫的時候使用,并且在每次你對 Podfile
文件編輯的時候(添加、更新、刪除)使用。
每一次運行pod install
命令后,都會去下載安裝新的庫,并且會修改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
中記錄的有最新版本的庫,意思是,如果你進行了pod update PODNAME
操作,只要這些庫符合Podfile.lock
中的版本限制(如pod MyPod, ‘~>x.y’
),那么它就會更新。
pod update
當你運行了 pod update PODNAME
命令,CocoaPods將不會考慮Podfile.lock
中列出的版本,而直接去查找該庫的新版本。它將更新到這個庫盡可能新的版本,只要符合Podfile
中的版本限制要求。
如果使用pod update
命令不帶庫名稱參數,CocoaPods將會去更新Podfile
中每一個庫的盡可能新的版本。
正確的用法:
使用pod update PODNAME
可以去更新一個庫的指定版本(檢查相應的庫是否存在更新的版本,并且更新),相對應的,使用pod install
將不會更新那些已經下載安裝了的庫。
當你在Podfile
中添加了一個新的庫時,你應該使用pod install
命令,而不是pod udpate
,這樣安裝了新增的庫,也不會重復安裝已經存在的庫。
使用pod update
僅僅只是去更新指定庫的版本(或者全部庫)。
提交你的Podfile.lock文件:
提醒一下,即使你一向不commit你的庫文件到你的共享倉庫,你也應該總是commit & push到你的Podfile.lcok
文件中。
否則,就會破壞掉pod install
的整個設計邏輯,造成Podfile.lock
文件無法鎖定你已經安裝的庫。
場景應用:
這里有一個場景示例來展示在項目的聲明周期中各種方案的使用。
例1:用戶1創建了一個項目
用戶1創建了一個工程,并且想使用A
、B
、C
這三個庫,所以他就創建了一個含有這個三個庫的Podfile
文件,并且運行pod intall
命令。
這樣就會安裝了A
、B
、C
三個庫到這個工程里面,假設我們的版本都為1.0.0
。
因此Podfile.lock
將會跟蹤并記錄A
、B
、C
這三個庫以及它們的版本號1.0.0
。
順便說一下:因為第一次運行pod install
,并且Pods.xcodeproj
工程文件還不存在,所以這個命令會同時創建Pods.xcodeproj
以及.xcworkspace
工程文件,這只是這個命令的一個副作用,但不是主要目的。
例2:用戶1添加了一個新庫
其后,用戶1添加了一個庫D
到Podfile
文件中。
然后他就運行pod install
命令了。因此即使庫B的開發者發布了B的一個新版本1.1.0
。但只要是在第一次執行pod install
之后發布的新的版本,那么B的版本使用的仍然是1.0.0
。因為用戶1只是希望添加一個新庫D
,不希望更新庫B
。
這就是很多人容易出錯的地方,因為他們在這里使用了
pod update
,而不是pod install
,可能是想著“我要更新一下我工程中的庫”。
例3:用戶2加入到工程中
用戶2是一個之前沒有參與到這個工程的人,稍后加入到項目中。他使用pod install
命令克隆了代碼倉庫。
如果Podfile.lock
被提交到git倉庫中,那么Podfile.lock
的內容就會確保用戶1和用戶2會得到完全一樣的庫。
即使庫C
已經有了到了1.2.0
版本,用戶2使用的庫C
仍然是1.0.0
版本,因為庫C
已經在Podfile.lock
里面注冊過了,庫C
的1.0.0
版本已經在Podfile.lock
中被鎖住了。
例4:檢查某個庫的新版本
之后,用戶1想檢查pods里面是否有可更新的庫時,他執行了 pod outdated
,這個命令將會羅列出來:庫B
有了新版本1.1.0
,庫C
有了新版本1.2.0
。
用戶1決定更新庫B
,但不更新庫C
,所以執行pod update B
,這樣就把庫B從1.0.0
更新到1.1.0
(同時更新Podfile.lock
中相應的庫B
的版本記錄),此時,庫C
仍然是1.0.0
版本,不會被更新到1.2.0
。
在Podfile
中使用明確的版本還不夠
有些人可能認為在Podfile
中指定某個庫的版本已經足以保證所有項目團隊中的人都會使用完全一樣的版本,比如:pod 'A', '1.0.0'
。
然后,他們可能認為此時如果添加一個新庫的時候,我使用pod update
并不會去更新其它的庫,因為其它的庫已經被限定了固定的版本號。
但事實上,在以上場景中,這不足以保證用戶1和用戶2用到的庫版本完全一樣。
一個典型的例子是,如果庫A對A2
有一個依賴(比如聲明在A.podspec
中:dependency 'A2', '~> 3.0'
),這樣的話,在你的Podfile
中使用 pod 'A', '1.0.0'
將會讓用戶1和用戶2都使用同樣版本的庫A(1.0.0
)。
但是,用戶1最后可能使用的是版本為
3.4
的庫A2
(因為3.4
是當時用戶1使用的最新版本)。用戶2稍后加入到項目中,使用
pod install
安裝庫,得到的庫A2版本可能是3.5
(假設A2
的開發者剛剛發布了A2
的新版本3.5
)。
這就是為什么使用Podfile.lock
這一個方式來保證參與項目的每個開發者的電腦中都使用相同版本的庫,并且合理的使用pod install
和 pod update
。