Tag: 包管理

宣布可可足类产生

抬起头，我们已经搬家了！ 如果您想继续了解Square的最新技术内容，请访问我们的新家https://developer.squareup.com/blog 在Square，我们将CocoaPods用作iOS开发工作流程的核心部分，除了在测试套件中使用的库之外，仅在Square Point of Sale应用程序中就有大量库。 这些库中有许多都生活在我们的主要iOS monorepo中，并且随着应用的增长，构建整个库所需的时间也越来越长。 CocoaPods允许我们将所有库配置保留在易于阅读的podspec文件中，与Xcode项目相比，在pull请求中查看它要容易得多。 我们的项目配置很少在Xcode本身中进行管理，这确保了文件系统与Xcode中所见内容之间的一致性。 但是，将所有这些模块集成到单个项目中存在一些缺点。 尽管我们已经投入了很多精力来改善安装依赖项的整体性能，但是运行单个pod install命令可能需要一到两分钟，这在快速迭代单个库时会加起来。 使用CocoaPods还会生成一个非常大的Pods项目，这可能导致Xcode的响应速度变慢，并且需要很长时间才能建立索引。 随着这种爆炸性的增长，显然我们需要开发人员更好的工作方式。 我们希望能够隔离地处理模块，仅构建正在积极处理的模块并仅运行随附的测试套件。 输入pod gen。 我们构建了一个CocoaPods插件，该插件使iOS开发人员可以轻松地独立处理各个库，尤其是在monorepo的情况下。 运行此插件将生成一个存根应用程序项目，该项目将集成并链接指定的库及其依赖项。 我们完整的Pods项目大约需要95秒才能生成，并且是35.6万行。 如果我们在U​​I组件库上运行pod gen，则将花费5秒钟并生成9000行项目文件。 这使得在这些基础库上的迭代变得如此快，并且工具可以轻松地处理较小的规模。 关于gen的最酷的事情是它会自动从现有Podfile和Podfile.lock中引入依赖项限制，因此所有配置都将在生成的库工作区中进行镜像。 这不仅在用于独立开发的monorepo上下文中有用。 当与可从podspec中描述测试的功能结合使用时，它在独立的存储库中也可以很好地工作。 这使独立库可以避免检入和维护自己的Xcode项目，因为CocoaPods可以对其进行管理。 这意味着您不再需要处理PR中的Xcode冲突，因为.xcodeproj只是生成的用于开发的工件。 podspec本身成为描述您的库的真理源，您可以使用简单的pod gen命令从中生成工作区。 可以简单地将测试放在文件系统中的相应文件夹中，并将其作为CI的一部分运行。 例如，我们设置了这个演示仓库，我们需要签入的唯一配置是podspecs。 我们已经在内部使用这种宝石几个月了，很高兴与世界分享它！

豆荚，迦太基和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或其他语言的其他软件包管理器所没有的某种程度的控制，那就是完全控制。 刚开始创建运行脚本并将框架链接到项目似乎很困难，但是一旦习惯后，该过程将变得异常顺利。 […]