您在软件包索引中看到的大部分信息都是从单个 URL 生成的,即软件包的 git 仓库的位置。
从该 URL,我们从仓库本身、软件包清单、GitHub API(是的,目前仅限 GitHub,但我们确实计划支持其他主机)以及运行软件包的构建来检查与操作系统和 Swift 版本的兼容性来收集数据。
边缘情况
当然,与软件开发中的所有事情一样,您很快就会发现自己在谈论边缘情况。
在创建构建系统时,我们很快遇到了 watchOS 目标构建失败的软件包。我们在运行构建时使用 Xcode 的自动 scheme 创建功能,但 Xcode 生成的 scheme 总是包含测试目标,而 XCTest
在 watchOS 上不可用。对 watchOS 构建使用自动 scheme 是行不通的。
使这些构建成功的唯一方法是让我们的构建系统使用特定的 scheme,而不是自动创建的 scheme。许多软件包已经为此目的设置了 scheme,但由于软件包作者可以为 scheme 命名任何名称,因此不容易发现它们。
引入 Swift Package Index 配置文件
我们需要的不是试图保持构建系统 100% 通用,而是需要一种机制,让软件包作者可以指定一些配置信息,例如用于构建 watchOS 目标的 scheme 名称。
我们通过配置文件 .spi.yml
来支持这一点,我们将在您的 Swift 软件包仓库的根目录中查找该文件。
watchOS 的 Scheme
您可以看到流行的软件包 swift-composable-architecture
由 Pointfree 使用了 此配置文件
version: 1
builder:
configs:
- platform: watchos
scheme: ComposableArchitecture_watchOS
我们的构建服务器会查找此文件,并使用我们为每个平台找到的任何 scheme 信息。如果未列出平台,我们将使用我们的默认启发式方法来确定 scheme,如我们的构建常见问题解答中所述。
Linux 的镜像
自定义 scheme 并非我们支持的全部。软件包作者还可以使用 .spi.yml
文件为我们的 Linux 构建配置自定义 docker 基础镜像。
我们使用 docker 命令为 Linux 构建软件包,在 Apple 提供的各种基础镜像之间进行选择。
/usr/local/bin/docker run --rm -v "$PWD":/host -w /host swiftlang/swift:5.2.4 swift build --enable-test-discovery
这在软件包需要操作系统级别的依赖项(如 OpenSSL)时效果不佳。
我们最终可能会为支持的 Swift 版本提供我们自己的一组基础镜像,其中还包括常见的依赖项,如 OpenSSL。目前,我们要求构建因缺少依赖项而失败的软件包作者为他们支持的 Swift 版本创建自己的镜像。
出于安全原因,我们不允许软件包作者在配置文件中指定任意镜像,因此如果您需要使用此功能,请提出 issue 要求我们支持自定义基础镜像。
AWS 库 Soto 是一个在其 .spi.yml
文件中使用了此功能的软件包示例
version: 1
builder:
configs:
- platform: linux
swift_version: '5.0'
image: adamfowlerphoto/aws-sdk-swift:5.0
- platform: linux
swift_version: '5.1'
image: adamfowlerphoto/aws-sdk-swift:5.1
- platform: linux
swift_version: '5.2'
image: adamfowlerphoto/aws-sdk-swift:5.2
- platform: linux
swift_version: '5.3'
image: adamfowlerphoto/aws-sdk-swift:5.3
未来方向
此配置文件仍处于早期阶段。我们创建它是为了解决软件包作者在努力确保我们报告的语言和平台兼容性反映现实时面临的问题。
我们预计此文件会不断发展,这就是它带有版本号的原因。以下是我们计划在未来添加的一些内容,以便软件包作者可以控制它们
- 作者元数据。全名、博客 URL、Twitter 帐户等。
- 软件包关键字或类别。
- 软件包托管文档的位置。
- 软件包的赞助或资助信息。
在 此 GitHub issue 中讨论了更多元数据可能性。如果您有建议,这是一个发表意见的好地方。
文件格式
我们选择 YAML
作为文件格式,因为它是一种无争议、普遍受欢迎的格式,并且完全没有问题。 😬
说真的,我们选择 YAML 是因为它相对容易让人阅读和编写,并且在 Swift 中得到很好的支持。虽然与 JSON 相比它有一些缺点,但我们认为考虑到软件包作者需要手动创建此文件,它是一种更实用的格式。
当然,我们将让采用情况来指导它在实践中的运作情况!