第3節 Pod install 與 update · Cocoapods使用指南

[TOC] # 1. 介紹許多以 CocoaPods 開始的人似乎認為 `pod install` 僅在您第一次使用 CocoaPods 設置項目時使用，并且之后使用 `pod update`。但事實并非如此。本指南的目的是解釋何時應使用 `pod install` 以及何時應使用 `pod update`。 * 使用 `pod install` 在您的項目中安裝新的 pods。即使您之前已經有了 Podfile 并運行了 `pod install`，所以即使你只是添加/刪除 pods 到已經使用 CocoaPods 的項目。 * 僅當您想將 Pod 更新為新版本時才使用 `pod update [PODNAME]`。 # 2. 命令的詳細介紹 > 注意：安裝與更新的詞匯并不是特定于 CocoaPods 的。它受到了許多其他依賴管理器的啟發，如 [Bundler](http://bundler.io/)，[RubyGems](https://rubygems.org/) 或 [composer](https://getcomposer.org/)，它們都有類似的命令，其行為和意圖與本文檔中描述的完全相同。 ## 2.1 pod install 這是在您第一次檢索項目的 pod 時使用的，也是每次編輯 Podfile 以添加，更新或刪除 pod 的時候使用的。 * 每次運行 `pod install` 命令并下載并安裝新的 pod 時，都會在 Podfile.lock 文件中為每個 pod 寫入已安裝的版本。該文件會跟蹤每個 pod 的安裝版本并鎖定這些版本。 * 運行 `pod install` 時，它僅解決 Podfile.lock 中未列出的 pod 的依賴關系。 * 對于 Podfile.lock 中列出的 Pod，它會下載 Podfile.lock 中列出的顯式版本，而不嘗試檢查是否有更新的版本可用 * 對于沒有在 Podfile.lock 中列出的 pod，它會搜索與 Podfile 中描述的內容相匹配的版本（例如在“Pod”中，如 `'Pod'，'?> 1.2'`） ## 2.2 pod outdated 當您運行 `pod outdated` 時，CocoaPods 將列出所有具有比 Podfile.lock 中列出的更新版本的 pod（當前為每個 pod 安裝的版本）。這意味著如果您在這些 pod 上運行 `pod update PODNAME`，則只要新版本與您的 Podfile 中設置的`pod'MyPod'，'?> x.y'` 等限制匹配，它們就會更新。 ## 2.3 pod update 當您運行 `pod update PODNAME` 時，CocoaPods 將嘗試查找 pod PODNAME 的更新版本，而不考慮 Podfile.lock 中列出的版本。它會將 pod 更新為最新版本（只要它符合 Podfile 中的版本限制）。如果您運行沒有 pod 名稱的 `pod update`，CocoaPods 會將 Podfile 中列出的每個 pod 更新為最新版本。 # 3. 預期用法使用 `pod update PODNAME`，您將只能更新特定的 Pod（檢查是否存在新版本并相應地更新 Pod）。與之相反， `pod install` 不會嘗試更新已安裝的 pod 版本。當您向 Podfile 添加 Pod 時，應該運行 `pod install` ，而不是 `pod update` - 安裝此新 Pod，而不必擔心在同一進程中更新現有Pod。當您想要更新特定 Pod（或所有Pod）的版本時，您只能使用 `pod update` 。 # 4. 提交你的 Podfile.lock 提醒一下，即使您的策略不是將 Pods 文件夾提交到共享存儲庫，也應該始終提交并推送您的 Podfile.lock 文件。否則，它會打破上面解釋的關于 pod 安裝能夠鎖定已安裝版本的 pod 的整個邏輯。 # 5. 場景示例以下是一個場景示例，用于說明在項目生命周期中可能遇到的各種用例。 ## 5.1 階段1：用戶1創建項目 user1 創建一個項目并希望使用 pod A，B，C。他們使用這些窗格創建 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，但這是該命令的副作用，而不是其主要功能。 ## 5.2 階段2：用戶1添加一個新的窗格稍后，user1 想要將 Pod D 添加到其 Podfile 中。因此，他們應該在之后運行 `pod install`，以便即使 pod B 的開發人員在第一次執行`pod install` 后發布了 pod 的 1.1.0 版本，該項目仍會繼續使用 1.0.0 版本 - 因為user1 只需要添加 Pod D，而不會冒著對 Pod B 的意外更新的風險。 > 有些人認為它錯了，因為他們在這里使用 `pod update` - 可能認為這是“我想用新的 pod 更新我的項目”？ - 而不是使用 `pod install` - 在項目中安裝新的 pod 。 ## 5.3 階段3：用戶2加入該項目然后，從未參與過該項目的用戶2加入該團隊。他們克隆倉庫，然后使用 pod 安裝。 Podfile.lock（應該提交到git倉庫）的內容將確保它們將獲得完全相同的 pod，并且使用與user1完全相同的版本。即使版本 1.2.0 的版本 C 現在可用，user2 也將獲得版本 1.0.0 中的版本 C. 因為這是在 Podfile.lock 中注冊的內容。 pod C 被 Podfile.lock 鎖定為版本 1.0.0（因此是該文件的名稱）。 ## 5.4 階段4：檢查一個Pod的新版本稍后，user1 需要檢查是否有任何更新可用于 pods 。他們運行 `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）。 # 6. 在 Podfile 中使用精確的版本是不夠的有些人可能會認為，通過在其 Podfile 中指定其 Pod的精確版本，例如pod'A'，'1.0.0'，足以保證每個用戶都擁有與團隊中其他人相同的版本。然后，他們甚至可以使用 ` pod update `，即使只是添加一個新Pod，也認為從來不會冒更新其他 Pod 的風險，因為它們固定到 Podfile 中的特定版本。但事實上，這還不足以保證我們上述場景中的 user1 和 user2 將始終獲得完全相同版本的所有 Pod 。一個典型的例子是，如果 pod A 依賴于 pod A2 - 在 A.podspec 中聲明為依賴關系 `'A2'，'?> 3.0'` 。在這種情況下，在 Podfile 中使用 pod'A' ， '1.0.0' 確實會強制user1 和 user2 都使用 pod A 的版本 1.0.0，但是： * user1 最終可能會在版本 3.4 中得到 A2 （因為那時是A2的最新版本） * 而當 user2 稍后加入項目時運行 `pod install` 時，他們可能會在版本 3.5 中獲得 pod A2（因為 A2 的維護者可能同時發布了新版本）。這就是為什么確保每個團隊成員使用每臺計算機上所有pod的相同版本的唯一方法是使用 Podfile.lock 并正確使用 `pod install` 與 ` pod update `。