豆荚，迦太基和SPM：Swift的包装管理困境

到2019年，Swift已从Apple的少数几个开源项目之一发展成为一种功能强大的语言，成为Apple系统开发背后的强大力量，甚至还扩展到了Linux等其他操作系统。 现在处于4.2版中，期待已久的Swift 5发行版，Swift因其协议定位和为多个平台编写本机应用程序的能力而变得非常流行。

Swift 3是所有Swift用户和开发人员的标志性版本：它是代码破解版本，更改了大多数语法，删除了语言方面并添加了其他内容，并引入了其他主要工具和增强功能，例如Swift Package Manager和Swift Linux的核心库。 但是，随着Swift 3的到来，对开发人员来说，另一个艰难的决定。 Swift软件包管理器（Swift Package Manager）是Swift开发人员的第三个软件包管理器，但也是第一个正式软件包管理器，现已投入使用，使库和框架的选择和分发过程更加多样化。

Swift的包装管理困境

Google的词典将困境定义为“必须在两个或多个替代方案之间做出艰难选择的情况，尤其是同样令人讨厌的替代方案。”现在，我不会说所有可用的软件包管理器都是令人讨厌的，但我可以同意，它们都不是完美的。 与任何软件一样，程序包管理器都有其成功之处和不足之处，尽管每种缺点在开发中使用时都可能导致麻烦。 Swift的三个主要包管理器是Cocoapods，Carthage和Swift包管理器（SPM）。

Cocoapods是该小组中的老大，自从Objective-C是Apple的主要软件开发语言以来就一直存在。 Cocoapods最初于2011年9月17日发布，最初是为使用面向对象的C风格语言的库和框架提供服务的，为随之而来的软件包管理者铺平了道路。 当Swift成为主流时，Cocoapods慷慨地扩展到包括新语言的库和框架，新语言是其他程序包管理器将在以后建立的语言。 当2014年11月到来时，下一个软件包管理器发布了，这意味着Cocoapods不再是使用Xcode的那些的唯一发行商。 多种选择的能力都很强，这使得最初的Swift软件包管理器引起了争议。 尽管许多人认为它对Swift和Objective-C开发人员来说是革命性的，但其他人却因为它的明显缺点对其进行了轰炸。

• Cocoapod最显着的功能之一就是它完全自动化了依赖程序，开发人员只需运行pod install ，Cocoapods便会获取并构建依赖项，将其插入项目中，将其链接到项目中，并生成一个包含两者的工作区。项目和豆荚。 事实证明，虽然该功能是主要的便利，但开发人员并不完全满意：尽管该过程确实节省了他们大量的时间和精力，但它也将对项目的控制权移交给了Cocoapods并让其处理文件和项目设置。 开发人员感到这是一种无声的痛苦，直到下一个程序包管理器发布时，这种痛苦才得以表达。 随着时间的流逝，开发人员对允许流行的第三方掌控为其项目构建程序包的满意度越来越低。
• 尽管较新的软件包管理器是用Swift编写的，但对于Swift而言，Cocoapods是用Ruby编写的，这意味着开发人员确实需要熟悉该语言才能操作软件包管理器。 许多人确实知道Ruby，而且学习曲线并不复杂，因此添加另一种语言的文件带来的不便并不麻烦。 但是，Swift的软件包管理器不是用自己的语言（例如Nuget，PyPi或NPM）编写的，而不得不使用另一种语言的事实给开发人员带来了痛苦。
• Cocoapods是集中式的，这在软件包管理器中很常见（一个常见的指标是软件包注册表）。 程序包管理器中的集中化意味着存在一个中央代码注册表，可以在其中托管和查看程序包，并且客户端（通常是命令行界面）可以从中提取代码以生成程序包。 可以从cocoapods.org上浏览其网络上托管的所有Pod，这对于那些没有特定软件包或只想浏览可用软件包的开发人员来说非常有用。 但是，许多人似乎对新的分散化概念感到迷惑，这意味着Cocoapods不再是理想的包裹管理系统。

尽管Cocoapods有其缺点，并且最近一直受到嘲笑，但是它仍然是Swift的包管理器中最古老的，并且由于其自动化，对初学者非常友好。

CocoaPods.org
iOS和Mac项目的依赖管理器 cocoapods.org

迦太基是第二位进入该小组的包装经理，从一开始它就与Cocoapods的主要区别显而易见。 它于2014年11月18日发布，在Swift 1.1正式发布后仅两个月就可用，并且支持Swift中的Objective-C。 迦太基在Cocoapods中发现了一个对开发人员来说很酸的话题：虽然Cocoapods是用Ruby编写的，但是Carthage完全用Swift编写了一个包管理器来迎合用户。 除了以Apple支持的语言以及您的项目被编写时，依赖管理的强大功能之外，Carthage还声称它利用Xcode的构建系统，同时为开发人员提供了集成其依赖的自由。 通过迦太基，开发人员可以控制他们项目的依赖关系，从而使他们能够在迦太基构建之后，根据自己的选择进行链接和管理。

• 第一次学习如何将Carthage集成到您的项目中（以及随后针对更复杂的需求）时，Carthage的README具有令人难以置信的描述性和实用性，但是对于经验较少的开发人员来说，开始使用它可能非常复杂。 但是，随着集成过程的延长，从长远来看，它将带来更多的简化和控制。 设置好迦太基并链接了依赖项后，只需要将一行添加到一个非常简单的文件（而不是将一行或多行添加到Ruby文件）和一个命令， carthage update ，就可以生成新的框架。可以导入原始文件的方式。 迦太基消除了在较大的.xcworkspace中处理多个.xcproject文件的麻烦，并消除了与核心项目一起添加的庞大文件结构，而仅在项目根目录中使用.framework文件夹对项目进行了补充，该文件夹清楚地说明了名称。框架。
• 迦太基提供了Swift，Objective-C或其他语言的其他软件包管理器所没有的某种程度的控制，那就是完全控制。 刚开始创建运行脚本并将框架链接到项目似乎很困难，但是一旦习惯后，该过程将变得异常顺利。 通过手动添加到项目并进行链接，一旦迦太基构建了依赖关系，开发人员就可以精确控制依赖关系。 如果开发人员确定他们在项目中不需要框架，则无需编辑Cartfile并更新所有依赖项； 他们可以从Xcode项目中删除框架，并从运行脚本中删除链接命令。
• 最近，权力下放一直在上升，对于采用其原则的软件来说，2018年是丰收的一年。 尽管迦太基于2014年创建，但可以说它是软件界的早期采用者，尽管计算机去中心化在相当长的一段时间内一直很流行，尤其是在加密货币中。 Carthage是一个分散的软件包管理器，这意味着没有核心服务器，也没有项目的集中列表。 相反，包管理器可以访问各个GitHub存储库，以获取要构建到框架中的代码。 尽管这确实使与Carthage兼容的框架的定位变得复杂，但这确实意味着Carthage更加安全，并且利用了开发人员开始喜欢的概念。 同样，这确实意味着迦太基在寻求和建立依赖关系时可能比Cocoapods慢，但是如果要进行取舍，这是开发人员的选择。

迦太基在如何执行软件包管理方面具有革命性，乍一看可能很复杂，但它确实是杰出的软件包管理器，允许开发人员控制其依赖项。

迦太基/迦太基
Cocoa的简单，分散式依赖管理器– Carthage / Carthage github.com

Swift软件包管理器是最新加入Swift软件包管理器的人员，它于2016年9月13日随着Swift 3的发布而推出。与其他Swift软件包管理器相比，Swift软件包管理器与其他语言的同类软件包更加相似，对于来自另一种语言的人来说更容易接手。 它将为您的项目添加文件结构，使来自Cargo或NPM的任何人都感到宾至如归，将每个依赖项组织到代表模块的自己的文件夹中。 设置用于iOS，Mac和Linux的开发同样简单，这是其他软件包管理器似乎缺少的一种功能。 管理器的清单也类似于其他语言，具有特定的类似于JSON的结构。

• Swift软件包管理器是新的，内置于​​Swift语言中（因此无需安装任何东西！），并且几乎总是在Swift和Xcode发行后立即对其进行最新更新。 由于它最初是由Swift 3构建的，并且经常更新，因此避免了遗留代码的问题以及需要频繁更新的问题，而这是其他程序包管理器需要做的事情。 命令行界面直接集成到Xcode和Swift构建过程中，这意味着在Package.swift文件之外无需声明其他依赖项即可进行其他配置。
• Swift软件包管理器带有Cocoapods和Carthage缺乏的重要签名：Apple的邮票是Swift的官方软件包管理器。 它是在Apple公开开放下开发的，并得到了社区的贡献。它共享了受开发人员欢迎的开源方面，并被Swift的其他程序包管理器使用。 苹果公司的支持和他们的团队与核心开发的合作使Swift Package Manager的效率和可信度得到了提高，这意味着开发人员可以加速和简化其构建过程，同时知道他们正在使用Mac或Mac上可用的最佳软件包管理软件来构建依赖项。 Linux for Swift语言。 尽管有些开发人员不是Apple及其政策和方法的忠实拥护者，但很难否认Swift Package Manager是他们的伟大创造。
• 所有著名的编程语言，以及许多开发人员可能从未听说过的语言，都有自己的包管理器，可以将第三方框架和库分发给开发社区。 Cocoapods与其他程序包管理器的不同之处在于其使用另一种语言和进行总项目操纵，而Carthage则由于其对开发者的控制权和分散性而有所不同。 Swift Package Manager的形式类似于其他语言的形式，这意味着曾经处理过依赖项的开发人员都会对此感到满意。 CLI中的命令与其他软件包管理器中的命令相似，Package.swift文件与Kotlin的Manifest.json或JavaScript的Package.json非常相似，并且文件在它们要添加到的项目中所采用的结构是与其他语言的结构几乎相同。

Swift软件包管理器被视为Swift项目中依赖管理的未来，它的效率和简便性为实现这一预测铺平了道路。

Swift.org
Swift是一种通用的编程语言，使用安全性，性能和软件的现代方法构建而成…… swift.org

用一种语言编写的三个熟练的软件包管理器对于开发人员来说可能是一个负担，无论他们选择合适的软件包还是开发要在其他项目中使用的软件包（通过管理器分发）。 Swift的困境不仅包括依赖性管理的多样性，而且每个软件包管理器都远非完美无缺，可能还有很多不足之处。 Cocoapods用户希望它不是用Ruby编写的，并且希望它不会过多地处理他们的项目，Carthage用户希望该过程有时不会那么复杂或缓慢，而Swift Package Manager的用户希望它不会那么复杂。与其他语言的打包管理器混淆或混为一谈。 从积极的方面来看，Swift的程序包管理系统虽然还不够完善，但它允许开发人员进行选择，而这是其他语言所不容易或根本无法实现的。

后记

那么，Swift的软件包管理困境是什么？ Swift具有多个软件包管理器，每个软件包管理器都有其优点和缺点，并且在选择一个或多个开发库和框架供其他人使用时需要采取的额外步骤时，需要考虑许多因素。 尽管这可能是一个难题，但Swift的多个程序包管理器各自包含的方面与其他语言中的相应包不同，这使得Swift中的依赖项构建和实现过程以其自己的方式独特而强大。