CocoaPods 1.0 迁移指南

1.0 主要更改 TL:DR

​

  • 您现在必须定义目标。以前有一个可用的隐式目标。
  • target 必须表示 Xcode 目标。
  • 当您想要表示一个包含多个目标的 Pod 集合时，请使用 abstract_target，然后在其中添加目标。嵌套目标继承 Pod 依赖项。
  • 希望了解目标的 Pod 但不需要链接的目标（例如，测试目标）可以通过其搜索路径定义它们继承 Pod（inherit! :search_paths）。
  • :exclusive => true 和 link_with 已被移除，取而代之的是上述内容。
  • xcodeproj 已重命名为 project，以使 DSL 词汇保持一致。
  • 我们已经移除了在 pod 上声明 :head 的功能 - 您既可以使用 :podspec 选项，也可以直接指向上游存储库（通过 git、:svn 等）。
  • 您现在可以通过 install! 在 Podfile 中声明安装选项（例如 install! 'cocoapods', :deterministic_uuids => false, :integrate_targets => false）。
  • 我们已经移除了所有被归类为已弃用的 DSL 属性。
  • 引入了 pod trunk delete 和 pod trunk deprecate。
  • pod search 改进（这很棒，因为它还会搜索您所有的私有规范存储库）。
  • pod lib lint 和 pod spec lint 将验证您的 Pod 是否可以实际导入。

重新定位目标

我们收到的很大一部分错误报告都是由于 Podfile 中的歧义造成的。它提供了很大的自由度来创建各种 CocoaPods 设置，这些设置将根据实现细节或工作而起作用，但比它们需要的要复杂得多。

在 0.x 分支中，目标的名称可以是任何内容。如果它是匹配目标的名称，那么它将自动链接到该目标，但如果不是，它将创建一个 Pods-[Name] 目标，您可以使用 link_to 将其连接到目标。

在 1.0+ 中，目标必须对应于一个真正的 Xcode 目标。为了支持 Pod 可以跨多个目标共享的用例，我们添加了 abstract_target。例如

# Note: There are no targets called "Shows" in any Xcode projects
abstract_target 'Shows' do
  pod 'ShowsKit'
  pod 'Fabric'

  # Has its own copy of ShowsKit + ShowWebAuth
  target 'ShowsiOS' do
    pod 'ShowWebAuth'
  end

  # Has its own copy of ShowsKit + ShowTVAuth
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end
end

注意：在此示例中，不使用 abstract_target 会更简单，但这是一个示例，所以请原谅我。

此更改强制执行 CocoaPods 目标之间更强的连接，并使创建如下所示的 Podfile 变得不可能

pod 'ShowsKit'

因为它具有模棱两可的行为。但是，以下内容是可能的，因为它声明了要链接到的目标

pod 'ShowsKit'
target 'ShowsiOS'

这有效，因为根级别被归类为未命名的 abstract_target。

更多示例

让我们看一个 非常常见的 示例，该示例作为 0.x pod lib create 发货。

source 'https://github.com/CocoaPods/Specs.git'
use_frameworks!

target 'ORStackView_Example', :exclusive => true do
  pod 'ORStackView', :path => '../'
end

target 'ORStackView_Tests', :exclusive => true do
  pod 'ORStackView', :path => '../'

  pod 'Quick'
end

这设置了两个完全独立的 CocoaPods 目标，它们彼此互斥。两者都有 ORStackView 库的副本。此 Podfile 中有很多内容；与更简单的 1.0 版本形成对比。

source 'https://github.com/CocoaPods/Specs.git'
use_frameworks!

target 'ORStackView_Example' do
  pod "ORStackView", :path => "../"

  target 'ORStackView_Tests' do
    inherit! :search_paths

    pod 'Quick'
  end
end

它具有明显的层次结构，因此你可以看到包含在 ORStackView_Example 中的 Pods 将包含在 ORStackView_Tests 目标中。唯一的新内容是 inherit! :search_paths，这意味着“不要将 Pods 链接到这里，但让此目标知道它们的存在”。此 Podfile 更易于阅读、更简单且冗余信息更少。

关闭 pods :head

将 :head 添加到 pod 几乎总是有效的，除了无效时。它记录如下

最后，你可以指定 :head 标志，而不是版本。这将使用 pod 的最新版本规范版本，但强制下载“最新”版本。请谨慎使用，因为规范可能不再与源材料兼容。

当 CocoaPods 规模较小且很难说服人们值得为其项目支持任何依赖项管理器时，它是一个非常有用的工具。那个时候早已过去，现在此属性最初提供的灵活性已经落到了“不值得保留”的一边。对于希望它意味着“使用其代码存储库的最新版本”的开发人员来说，它会引入极其难以调试的问题。你可以使用 :podspec 选项或直接指向上游存储库（通过 git、:svn 等）。

install! 的选项

过去，当我们必须支持 CocoaPods 的配置选项时，我们使用了环境变量。它们的作用类似于 NSUserDefaults，即知道密钥的人可以进行更改，但否则它们会保持相当隐藏。不过，有时它们也可以是命令行 API，例如 --no-integrate。虽然这些都是有意识的选择，但最终随着时间的推移变得不一致，我们选择支持将信息集中在 Podfile 中。您可以在指南中查看所有可用选项。

这意味着团队中的每位开发人员在 pod install 上都将获得相同的输出，无论其环境如何，无论是在CocoaPods.app中还是在命令行中。我们已经将 DSL 属性 install! 保持为开放状态，以便可以利用此属性构建未来功能。

为稳定性构建

1.0 的大量工作围绕着尝试简化 CocoaPods，以提供持久的架构。这一点尤其重要，因为 CocoaPods 构建的基础通常会在每年 6 月发生变化，并且该项目是由少数人在业余时间运行的。

我们还理解，运行 CocoaPods 是关于与人打交道。例如，对于我们的默认 CocoaPods Specs 存储库，自引入CocoaPods Trunk以来，我们一直坚持只读策略。但实际上，我们不得不相对定期地手动支持编辑和删除 Pod，而 CocoaPods 开发团队必须做出这些决定。借助 1.0.0，我们构建了支持删除和弃用 CocoaPod 和 CocoaPod 版本的基础架构。我们不建议这样做，但现在可以这样做，并且由库所有者决定是否允许其用户删除依赖项。

1.0

最后，可能也是最重要的一点。一旦测试版完成，我就可以摆脱此常见问题解答条目

“CocoaPods 尚未准备好投入使用。”

正确。1.0.0 版本将是我们的里程碑，届时我们有信心 Cocoa 依赖项管理器的所有基本要求都已得到满足。

一旦我们达到 1.0.0 里程碑，我们将首次通过 cocoa-dev 等邮件列表联系整个社区。

只要我一直在从事 CocoaPods 的基础设施/设计，它就一直困扰着我。

🎉