どちらでもSwiftを扱えるようになりつつある今
Cocoa関係のライブラリの依存管理としてはCocoaPodsがデファクトな状態でしたが、11月に新しいライブラリ依存管理システムのCarthageが登場しました。その時点ではCocoaPodsがまだSwift対応（ダイナミックフレームワーク対応)が遅れていたこともあり、各記事が盛り上がったり、対応してるSwiftライブラリも見かけるようになりました。
が、CocoaPodsもSwift対応の0.36 betaがクリスマスにリリースされ、どちらでもSwiftのライブラリが扱える状態が整いつつあります。
そんな状況で、それぞれの違いやできることについてザッと調べてるのですがCarthageのREADMEのDifferences between Carthage and CocoaPodsの項が参考になった＆面白かったので翻訳して載せておきます。
(翻訳)CocoaPodsとCarthageの違い
https://github.com/Carthage/Carthage/blob/master/README.md より
CocoaPods is a long-standing dependency manager for Cocoa. So why was Carthage created?
CocoaPodsは定番のCocoaの依存管理マネージャーです。なのに、なぜCarthageを作ったのでしょうか？
Firstly, CocoaPods (by default) automatically creates and updates an Xcode workspace for your application and all dependencies. Carthage builds framework binaries using xcodebuild, but leaves the responsibility of integrating them up to the user. CocoaPods’ approach is easier to use, while Carthage’s is flexible and unintrusive.
まず第１に、CocoaPodsは（デフォルトでは）、自動的にアプリケーション用のXcodeのワークスペースと全ての依存関係を作成及び更新を行います。Carthageはframeworkのバイナリをxcodebuildを使ってビルドしますが、プロジェクトへの統合まではせず、統合する作業はユーザに任せます。CocoaPodsのアプローチはユーザにとって使いやすく、一方でCarthage側は柔軟で押し付けがましくないアプローチです。
The goal of CocoaPods is listed in its README as follows:
… to improve discoverability of, and engagement in, third party open-source libraries, by creating a more centralized ecosystem.
CocoaPodsのゴールは、あちらのREADMEに以下のように書かれています
(注:以下はCocoaPodsのREADMEからの引用=CocoaPodsのゴール)
CocoaPodsのゴールは、より中央集中的なエコシステムを作ることで、 サードパーティ製のオープンソースライブラリを、より見つけやすく、より関わりやすくしていくことです。
By contrast, Carthage has been created as a decentralized dependency manager. There is no central list of projects, which reduces maintenance work and avoids any central point of failure. However, project discovery is more difficult—users must resort to GitHub’s Trending pages or similar.
対照的にCarthageは反中央集中型の依存管理マネージャーです。Carthageにはプロジェクトの一覧はありません、これはメンテナンスの仕事の負担を減らし中心障害点をなくすことができます。しかしプロジェクトを探す作業は難しくなります。ユーザはGithubのトレンディングページを並び替えたり、似たような方法でからプロジェクトを探す必要があります。
CocoaPods projects must also have what’s known as a podspec file, which includes metadata about the project and specifies how it should be built. Carthage uses xcodebuild to build dependencies, instead of integrating them into a single workspace, it doesn’t have a similar specification file but your dependencies must include their own Xcode project that describes how to build their products.
また、CocoaPodsプロジェクトはpodspec fileとして知られている仕組みを持っていて、そのファイルにプロジェクトやビルド方法の定義等のメタデータを記述します。Carthageは依存をビルドする際にワークスペースの中にプロジェクトを統合するのではなく、xcodebuildを使います。なので、そのような仕様用のファイルは必要ありません。しかし、プロジェクトをどのようにビルドするかの依存関係はプロジェクト自身のXCodeプロジェクトに含まれている必要があります。
Ultimately, we created Carthage because we wanted the simplest tool possible—a dependency manager that gets the job done without taking over the responsibility of Xcode, and without creating extra work for framework authors. CocoaPods offers many amazing features that Carthage will never have, at the expense of additional complexity.
結局のところ、私達は私達自身が、できるだけシンプルな依存管理マネージャーがほしかったからCarthageを作りました。
XCodeの役割を乗っ取ることなく、フレームワークの作者に余計な仕事を増やすことなく、動作するシンプルなものが。
CocoaPodsは(Carthageが決して持つことのない）驚くほど多くの機能を提供しています。複雑さが増えるという対価と引き換えに。
感想
Carthageは単に早めにダイナミックフレームワークに対応した依存管理システムというだけでなく、CocoaPodsに対する明確な不満から生まれ、別の点を目指してる依存管理システムであることがわかります。 他でできることは他に任せシンプルさを保つCarthageと、全てを請け負い何でもできるCocoaPods。
僕もCarthageを利用してみましたが、たしかにワークスペースなしで、XCodeの仕組みをそのまま使って動かすことができる点はシンプルで変なハマりかたすることも少なそうで良いなと思いました。
とはいえ既にCocoaPodsは普及しきっているので、CocoaPodsにしかないライブラリに依存すると結局ワークスペースが必要になるという点は気になります。といってもCarthageはSchemeをshareに設定するだけで対応できるので、もちろん自分でフォークしてCarthageに対応させたり、PR送って対応してもらう等は可能ですが。
あるいはReactive CocoaがCarthageのキラーライブラリになって一気に普及したりするのか…。…。趨勢が見えてくるまでには、しばらく時間がかかりそうですね。