這個是第一次在工程里面使用pods的時候使用,并且,也是每次你編輯你的Podfile(添加、移除、更新)的時候使用。
每次運行pod install命令的時候,在下載、安裝新的庫的同時,也會把你安裝的每個庫的版本都寫在了Podfile.lock文件里面。這個文件記錄你每個安裝庫的版本號,并且鎖定了這些版本。
當你使用pod install它只解決了pods里面,但不在Podfile.lock文件里面的那些庫之間的依賴。對于在Podfile.lock里面所列出的那些庫,會下載在Podfile.lock里面明確的版本,并不會去檢查是否該庫有新的版本。對于還不在Podfile.lock里面的庫,會找到Podfile里面描述對應版本(例如:pod “MyPod”, “~>1.2”)。
當你運行pod outdated命令,CocoaPods會列出那些所有較Podfile.lock里面有新版本的庫(那些當前被安裝著的庫的版本)。這個意思就是,如果你運行pod update PODNAME,如果這個庫有新的版本,并且新版本仍然符合在Podfile里的限制,它就會被更新。
當你運行 pod update PODNAME 命令時,CocoaPods會幫你更新到這個庫的新版本,而不需要考慮Podfile.lock里面的限制,它會更新到這個庫盡可能的新版本,只要符合Podfile里面的版本限制。
如果你運行pod update,后面沒有跟庫的名字,CocoaPods就會更新每一個Podfile里面的庫到盡可能的最新版本。
你應該使用pod update PODNAME去只更新某個特定的庫(檢查是否有新版本,并盡可能更新到新的版本)。對應的,你應該使用pod install,這個命令不會更新那些已經安裝了的庫。
當你在你的Podfile里面添加了一個庫的時候,你應該使用pod install,而不是pod update,這樣既安裝了這個庫,也不需要去更新其它的已安裝庫。
你應該使用pod update去更新某個特定的庫,或者所有的庫(在Podfile的限制中)。 提交你的Podfile.lock文件:
在此提醒,即使你一向以來,不commit你的Pods文件夾到遠程倉庫,你也應該commit并push到遠程倉庫中。
要不然,就會破壞整個邏輯,沒有了Podfile.lock限制你的Pods中的庫的版本。
舉例:
以下會舉例說明在各個場景下的使用。
場景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。
原文出處:https://guides.cocoapods.org/using/pod-install-vs-update.html
新聞熱點
疑難解答