椰子足与迦太基

很多时候，我们想知道如何管理对我们iOS项目的依赖。 从历史上看，这非常简单，因为选项非常有限。 从历史上看，我们使用Cocoapods是诚实的唯一有意义的选择，因为您既不想自己也不使用git子模块来管理它们。

过去的依赖管理

随着时间的流逝，我们意识到有新的选项可以管理依赖项。 当迦太基第一次出现时，我们也给了它一个机会，但它仍处于早期开发阶段，因此它具有很多令人讨厌的缺点。 不可能只为一个平台建立依赖关系，更新一个依赖关系而不更新其他依赖关系是不可能的，添加一个依赖关系而不编译其他依赖关系也是不可能的。 这样的事情只会让我们放慢脚步，因此我们决定坚持使用Cocoapods。 我们也不喜欢迦太基的哲学，因为我们喜欢运行pod install而不处理其他任何东西的想法。

迅速并发症

自从我们开始使用Swift作为主要的编程语言以来，我们面临着越来越多的麻烦-编译时间增加，语法高亮和SourceKit崩溃频繁。 我们开始想知道如何使我们的开发人员的生活更加愉快。 我们的第一个想法是看一下我们的依赖关系，因为它们是不变的代码，不需要被Xcode一次又一次地索引和编译。 这就是Carthage展示其优势的地方-依赖关系仅在框架中构建一次，仅此而已，不再需要建立索引，也无需进行编译。

迦太基反击

我们进行了一次尝试，Carthage似乎解决了所有早期开发阶段的问题，因此我们仅使用platform选项为iOS构建，而使用cache-builds选项跳过了已在本地编译的框架的编译。 结果真的很酷-语法突出显示变得更加可靠，并且构建时间减少了百分之几十。

这意味着，即使在功能不强的设备上，iOS开发也比15英寸Macbook Pro更舒适。 这也意味着我们决定以迦太基作为主要的依赖项管理器开始新项目。

我说主要的，尽管仍有一些不支持它的图书馆。 这些可能是较旧的存储库，它们不再维护或对我们无关紧要，因为我们尝试仅使用维护的库。 但是，某些专有软件使用静态库，这意味着它不能由迦太基管理。 在那些情况下，我们仍然使用Cocoapods。

持续的不便

但是，我们仍然遇到一些问题。 依赖项的初始编译时间可能会非常长，尤其是当依赖项包含多个子规范时（在Cocoapods术语中），因为Carthage会编译它们的全部（及其所有依赖项），即使项目不需要它们也是如此（为此存在拉动）迦太基github上的请求，这将减少这种不便，但目前仍未合并）。

我们也希望在项目之间进行一些本地缓存。 在我们的机器上，我们有更多的项目使用Carthage，并且经常使用相同版本的依赖项。 如果我们在每个项目中都运行迦太基引导程序 ，则即使它们的依赖关系可能是由以前的项目构建的，也可以建立依赖关系，这可以节省大量的构建时间。 也许与团队远程共享构建工件也很好。

由于我们的许多项目都使用Realm数据库，因此Carthage的空间利用率也可能更高一些-其工件占用大约1 GB的磁盘空间。 如果您有更多项目，则会很快损失很多空间。

仍然不是最好的

迦太基虽然极大地加快了我们的发展速度，但是仍然存在一些需要解决的问题。 也许现在可以通过使用正确的参数集来解决其中的一些问题，而另一些可以通过使用正确的工具（如Rome）来解决，但是那些提到的缺点可以很好地在迦太基内部集中解决。

分享是关怀

我们认为#sharing很重要，因此我们很乐意听到您如何管理依赖项。 您可以在下面给我们留下评论，或者在我们的Twitter，Github或Facebook上ping我们。