Just My Life & My Work

2013年就開始使用Cocoapods來使用第三方套件,儘管有發佈初學者的Cocoapods教學,可是在「管理」這方面卻還是有些不明白,像是pod install與pod update的差別,真的是要到需要的時候才會認真去釐清差異,過去一直install和update混著用,如今看官方說明就更明白,畢竟我今年開始是團隊合作寫iOS App囉!

文章開頭先說總結:團隊每人都要同步podfile.lock,如此能保證大家套件版本一致。

過去我以為只要Podfile指定好版本後就萬無一失,當時我獨自一人開發顯然不會有問題。然而遇到團隊如果要加入新人,只有Podfile無法保證下指令pod install後會跟資深同事版本一致,必須再參照記錄在podfile.lock中的套件,接著下指令pod install,才能保證版本一致。

現再來取用官方說明,能清楚了解兩者的差異!

pod install :

這個是第一次在工程裡面使用pods的時候使用,並且,也是每次你編輯你的Podfile(添加、移除、更新)的時候使用。

每次運行pod install命令的時候,在下載、安裝新的庫的同時,也會把你安裝的每個庫的版本都寫在了Podfile.lock文件裡面。這個文件記錄你每個安裝庫的版本號,並且鎖定了這些版本。

當你使用pod install它只解決了pods裡面,但不在Podfile.lock文件裡面的那些庫之間的依賴。對於在Podfile.lock裡面所列出的那些庫,會下載在Podfile.lock裡面明確的版本,並不會去檢查是否該庫有新的版本。對於還不在Podfile.lock裡面的庫,會找到Podfile裡面描述對應版本(例如:pod “MyPod", “~>1.2″)。

如圖,我在Podfile中移除一個RNCachingURLProtocol的套件。

pod update:

當你運行pod update PODNAME 命令時,CocoaPods會幫你更新到這個庫的新版本,而不需要考慮Podfile.lock裡面的限制,它會更新到這個庫盡可能的新版本,只要符合Podfile裡面的版本限制。

如果你運行pod update,後面沒有跟庫的名字,CocoaPods就會更新每一個Podfile裡面的庫到盡可能的最新版本。

另外來看一下一個有趣的指令~

pod outdated:

當你運行pod outdated命令,CocoaPods會列出那些所有較Podfile.lock裡面有新版本的庫(那些當前被安裝著的庫的版本)。這個意思就是,如果你運行pod update PODNAME,如果這個庫有新的版本,並且新版本仍然符合在Podfile裡的限制,它就會被更新。

來看看我install和update後podfile.lock的差異:

update

install

其他場景可以參考官方舉例的說明⋯⋯

場景1:User1創建了一個工程

User1創建了一個工程,並且想使用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:User1添加了一個庫

之後,User1添加了一個庫D到Podfile文件中。

然後他就應該運行pod install命令了。所以即使庫B的開發者發布了B的一個新版本1.1.0。但只要是在第一次執行pod install之後發布的,那麼B的版本仍然是1.0.0。因為User1只是希望添加一個新庫D,不希望更新庫B。

這就是很多人容易出錯的地方,因為他們在這裡使用了pod update,因為想著“更新我的工程一個新的庫而已”。這裡要注意!

場景3:User2加入到這個工程中

然後,User2,一個之前沒有參與到這個工程的人,加入了。他clone了一份倉庫,然後使用pod install命令。

Podfile.lock的內容就會保證User1和User2會得到完全一樣的pods,前提是Podfile.lock被提交到git倉庫中。

即使庫C的版本已經更新到了1.2.0,User2仍然會使用C的1.0.0版本,因為C已經在Podfile.lock裡面註冊過了,C的1.0.0版本已經被Podfile.lock鎖住了。

場景4:檢查某個庫的新版本

之後,User1想檢查pods裡面是否有可用的更新時,他執行了pod outdated,這個命令執行後,會列出來:B有了1.1.0版本,C有了1.2.0版本。

這時候,User1打算更新庫B,但不更新庫C,所以執行pod update B,這樣就把B從1.0.0更新到1.1.0(同時更新Podfile.lock裡面對B的版本記錄),此時,C仍然是1.0.0版本,不會更新。

在Podfile中使用明確版本還不夠

有些人認為在Podfile中明確某個庫的版本,例如:pod ‘A’, ‘1.0.0’ ,足以保證所有項目裡面的人都會使用完全一樣的版本。

這個時候,他們可能會覺得,此時如果添加一個新庫的時候,我使用pod update並不會去更新其它的庫,因為其它的庫已經被限定了固定的版本號。

但事實上,這不足以保證User1和User2的pods中庫的版本會完全一樣。

一個典型的例子是,如果庫A有一個對庫A2的依賴(聲明在A.podspec中:dependency ‘A2’, ‘~> 3.0’),如果這樣的話,使用pod ‘A’, ‘1.0.0 ‘ 在你的Podfile中,的確會讓User1和User2都使用同樣版本的庫A(1.0.0),然而:

最後User1可能使用A的依賴庫A2的版本為3.4(因為3.4是當時User1使用的最新版本),但User2使用的庫A2版本是3.5(假設A2的開發者剛剛發布了A2的新版本3.5)。

所以只有一個方法來保證某項目的每個開發者都使用相同版本的庫,就是每個電腦中都使用同樣的Podfile.lock,並且合理使用pod install 和pod update。

關於Podfile.lock

當你執行pod install之後,除了 Podfile 外,CocoaPods 還會生成一個名為Podfile.lock的文件,Podfile.lock 應該加入到版本控制裡面,不應該把這個文件加入到.gitignore中。因為Podfile.lock會鎖定當前各依賴庫的版本,之後如果多次執行pod install 不會更改版本,要pod update才會改Podfile.lock了。這樣多人協作的時候,可以防止第三方庫升級時造成大家各自的第三方庫版本不一致。

CocoaPods 官方文檔也在What is a Podfile.lock一節中介紹了Podfile.lock的作用,並且指出:

This file should always be kept under version control.

了然於心後,團隊合作就不用踩坑囉!話說比我早進公司的同事,當時就是pod update,讓專案起始開發同事搞了一陣子才排除問題XD~

參考:使用pod install還是pod update?pod install vs. pod update用CocoaPods做iOS程序的依賴管理

隨意留個言吧:)~

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

標籤雲

%d 位部落客按了讚: