创建您自己的 CocoaPod 非常简单。如果您已经有了单独的组件,那么您已经完成了大部分工作。本指南概述了整个过程,本部分中的其他指南为高级用户提供了更深入的了解。
我们建议让 CocoaPods 在此完成艰苦的工作。运行 pod lib create [pod name]
将为您设置一个经过深思熟虑的库结构,让您轻松包含您的文件并快速入门,我们为此提供了一个 指南。如果您希望了解整个过程的最新演练,直到推送到 trunk,请查看 tutsplus 的这个第三方 教程。
<Pod 文件
CocoaPod 和通用开源库之间只有少数几个区别。除了实际源代码之外,最重要的区别是 .podspec
和 LICENSE
。我们不接受没有代码许可证的库进入 trunk。有关选择何种许可证的信息,我们建议阅读 CodingHorror 上的这篇文章 或 tl;dr Legal。
<开发
您可以在系统上的文件夹中处理库。
或者,您可以使用
:path
选项从应用程序项目中处理
pod 'Name', :path => '~/code/Pods/'
<测试
您可以通过根据其目录的文件对 pod 进行 linting 来测试 Podfile 的语法,这不会测试 linting 的下载方面。
$ cd ~/code/Pods/NAME
$ pod lib lint
在向全世界发布您的新 Pod 之前,最好测试您是否可以成功将您的 pod 安装到 Xcode 项目中。您可以通过以下几种方式进行此操作
将您的 podspec 推送到您的存储库,然后使用 Podfile 创建一个新的 Xcode 项目,并将您的 pod 添加到文件中,如下所示
pod 'NAME', :git => 'https://example.com/URL/to/repo/NAME.git'
然后运行
pod install
-- or --
pod update
或者,如果您为单元测试有一个单独的 Xcode 项目,您可以为此项目使用引用您的开发 podspec 的 Podfile
xcodeproj 'NAMETests'
workspace '../NAME'
pod 'NAME', :path => '../'
<发布
一旦您准备好发布,您需要制作相应的标签。首先快速运行 pod lib lint
,然后创建您的标签并将其推送。
发布工作流程类似于以下内容。
$ cd ~/code/Pods/NAME
$ edit NAME.podspec
# set the new version to 0.0.1
# set the new tag to 0.0.1
$ pod lib lint
$ git add -A && git commit -m "Release 0.0.1."
$ git tag '0.0.1'
$ git push --tags
提交开源代码
一旦您的标签被推送,您就可以使用命令
pod trunk push NAME.podspec
将您的库发送到 Specs 存储库。有关获取此设置的更多信息,请参阅 Getting Setup With Trunk。
提交私有代码
一旦您的标签被推送,您就可以使用命令
pod repo push [repo] NAME.podspec
将您的库发送到指定的私有规范存储库。有关获取此设置的详细信息,请参阅私有 CocoaPods。
<库版本控制
不幸的是,开发人员经常无法很好地解释版本号,或将情绪价值赋予某些版本号。
但是,任意修订版作为版本对于库管理器来说不是一个好主意,而是一个正确的版本号(请参阅语义版本控制)。让我们解释一下,在理想情况下,我们希望人们如何与之交互
- “我想开始使用 CocoaLumberjack,当前版本现在就可以了。”因此,开发人员在库中添加了一个依赖项,没有版本要求,并且
pod install
将使用最新版本
pod 'CocoaLumberjack'
一段时间后,开发人员希望更新依赖项,为此再次运行安装命令,该命令现在将安装库的版本,该版本是当时的最新版本。
在某些时候,开发人员完成了客户端工作(或库的较新版本更改了 API,并且不需要更改),因此开发人员向依赖项添加了版本要求。例如,考虑库的作者遵循 semver 指南,您可以在一定程度上相信“1.0.7”和“1.1.0”之间不会进行任何 API 更改,而只会进行错误修复。因此,开发人员不必要求特定版本,而是可以指定只要高于“1.0.7”,则允许任何“1.0.x”。
pod 'CocoaLumberjack', '~> 1.0.7'
重点在于,开发人员可以通过再次运行pod install
轻松跟踪依赖项的较新版本,否则,如果他们必须手动更改所有内容,他们可能会减少这样做。CocoaPods 使用较不严格的语义版本控制形式,因为它不会强制您使用X.Y.Z
,您可以使用X.Y
版本。
<CocoaPods 版本控制规范
CocoaPods 使用 RubyGems 版本来指定 Pod 规范版本。RubyGems 版本控制策略描述了用于解释版本号的规则。RubyGems 版本规范符准确描述了如何使用指定依赖项版本的比较运算符。
遵循 RubyGems 中建立的模式,还可以在 CocoaPods 中指定预发布版本。例如,可以使用1.2-beta3
指定 1.2 版本的预发布版本。在此示例中,依赖项规范符~> 1.2-beta
将匹配1.2-beta3
。
谷歌有一个关于此工作原理的精彩视频:"CocoaPods 和 Squiggly Arrow 案例(第 85 条路线)"。
<记录 Pod
目前,获取有关记录 Pod 的信息的最佳位置是 NSHipster 博客文章,内容涉及 Obj-C 和 Swift 文档。 CocoaDocs 将在推送 Podspec 公共 API 后大约 15 分钟发布基于 appledoc/jazzy 解析的代码。有关 CocoaDocs 的更多信息,请参阅 CocoaDocs 开发人员自述文件
<我在哪里可以提问?
我们有多种支持途径,按我们偏好的顺序排列如下。
Stack Overflow,获得一些互联网积分。这可以减轻 CocoaPods 开发团队的压力,让我们有时间致力于项目而不是支持。使用 Stack Overflow 的一个优点是,其他人可以轻松访问答案。
CocoaPods 邮件列表,邮件列表主要用于发布相关项目的公告,偶尔也用于支持。