CocoaPods是否已經(jīng)準(zhǔn)備進(jìn)入黃金時(shí)段？為什么不只用git子模塊？等等。

1 “現(xiàn)在Swift已經(jīng)有了內(nèi)置的包管理器，CocoaPods會(huì)不會(huì)停止開(kāi)發(fā)？”

到本文撰寫(xiě)為止，Swift包管理器(SPM)還處在“早期設(shè)計(jì)和開(kāi)發(fā)階段”【1】。它當(dāng)前并不支持iOS，watch OS，或者Objective-C【2】【3】。在SPM開(kāi)發(fā)的同時(shí)，CocoaPods也會(huì)持續(xù)開(kāi)發(fā)以同時(shí)支持Swift和Objective-C。到SPM接近成熟的時(shí)候，我們將會(huì)評(píng)估CocoaPods和CocoaPods社區(qū)的最好的前進(jìn)方向。

2 “為什么不只用git子模塊？”

CocoaPods并不是用來(lái)下載代碼的。當(dāng)它完成下載工作時(shí)，這只是它最小的一部分功能。

對(duì)CocoaPods的定位是（交叉）依賴解決方案，（語(yǔ)義上的）版本管理，以及自動(dòng)“集成到Xcode中”。

最后，即使你僅把CocoaPods看成一個(gè)下載器，實(shí)際上也使用了其他的SCMs而不只是git。從另一個(gè)角度來(lái)看，CocoaPods是個(gè)黑盒，從本地或HTTP位置控制子版本、Mercurial以及zip/tarball壓縮。

3 “如何向CocoaPods捐贈(zèng)？”

簡(jiǎn)單的說(shuō)，我們非常感謝這份好意，本項(xiàng)目（作為一個(gè)實(shí)體）不接受經(jīng)濟(jì)捐贈(zèng)。我們有一片關(guān)于這個(gè)的博客帖子。

4 “CocoaPods做不了X，所以它沒(méi)什么用。”

請(qǐng)先看第二點(diǎn)（2），然后除非你告訴我們?nèi)笔Я耸裁垂δ芤约八鼮槭裁春苤匾駝t這種情況不可能存在。我們沒(méi)有擦去Twitter以查看工作，因此請(qǐng)做一個(gè) 標(biāo)記，或者最好是以“拉取請(qǐng)求”的方式

5 “CocoaPods并未做依賴解決方案。”

CocoaPods通常已經(jīng)做了依賴解決，但在0.35版本之前都缺少自動(dòng)處理沖突的解決方案。現(xiàn)在，CocoaPods已經(jīng)能夠解決所有可以解決的沖突。

6 “CocoaPods對(duì)團(tuán)隊(duì)有害，因?yàn)樗層脩籼菀滋砑舆^(guò)多的依賴。”

這等于在說(shuō)“我們不應(yīng)該有汽車”，因?yàn)樗鼈冏屛覀儜卸瑁覀兺浟俗呗?跑步。或者“我們不該使用IDEs”，因?yàn)樗鼈冏屛覀冏兂刹顒诺某绦騿T，不在編輯器中寫(xiě)代碼，并且記不得語(yǔ)法。此外，這個(gè)原因適用于獲取代碼（如，git）的根本意義，以及對(duì)于是否應(yīng)該有的討論。

然而值得討論的東西是，要讓用戶負(fù)責(zé)任。非常諷刺的是，CocoaPods最初的開(kāi)發(fā)者已經(jīng)被說(shuō)服了，也認(rèn)為使用大量的依賴不是好主意。關(guān)于如何解決這個(gè)問(wèn)題的切實(shí)可行的建議，你可以閱讀Manfred Stienstra寫(xiě)的這篇博客帖子。

7 “CocoaPods使用了工作空間，而工作空間被認(rèn)為是用戶數(shù)據(jù)。為什么不使用常見(jiàn)的子工程？”

從Xcode 4開(kāi)始，蘋果正是為了這個(gè)目的推出了工作空間。

從此以后，他們也在每個(gè)xcodePRoj文檔中添加了工作空間文件，這導(dǎo)致人們認(rèn)為工作空間只是用戶數(shù)據(jù)。這顯然錯(cuò)了，如果你曾經(jīng)這么認(rèn)為，那么你不應(yīng)該再忽略工作空間文檔了。

注意CocoaPods自身并不需要使用工作空間。如果你更喜歡使用子工程，你也可以這么做，只要運(yùn)行pod install –no-integrat，這將會(huì)讓你可以按照你看著爽的方式將pod庫(kù)整合到你的工程中。

8 “為什么我在使用CocoaPods前不得不安裝Ruby？”

你不是必須這么做，macOS自帶了Ruby 2.0.0或者更新的版本，預(yù)裝在/usr/bin/ruby目錄下，這是我們的基礎(chǔ)，我們必須在這個(gè)盒子里工作。

原文鏈接：《F.A.Q》