ITADN
commercialhaskell/stackage
代码 动态 Issues441 合并请求446 版本
commercialhaskell/stackage · 文件 下载 ZIP
文件最后提交记录最后更新时间
README.md
以下内容由 AI 翻译，如有问题请点此提交 issue 反馈

stackage

check

来自 Hackage 的稳定 Haskell 软件包集合

本仓库供软件包作者和维护者将其软件包纳入 Stackage。

如果您只是希望作为最终用户使用 Stackage，请遵循 stack 文档 或 https://www.stackage.org/#about 中的说明。

我们强烈建议使用 Haskell stack 工具进行构建，该工具内置了 Stackage 支持。

添加您的软件包

  • 要将您的软件包添加到 Stackage Nightly：请编辑 build-constraints 文件 并发起一个 PR。
  • 要将您的软件包添加到 Stackage LTS：您需要发起一个 pull request 以修改 lts-haskell 的 build-constraints。

我们欢迎所有软件包，前提是：

  • 来自 Hackage 的软件包能在当前的 Stackage 快照中构建
    • Stackage 仅使用来自 Hackage 的原始源代码（不允许对软件包进行任何补丁，包括版本边界，Hackage 修订版除外）
    • 特别是，该软件包必须与随 GHC 一起提供的核心库版本兼容（有关宽松下界的更多信息）。
  • 软件包的测试和基准代码 SHOULD 也能构建：如果可能，测试套件 SHOULD 也能通过。
    • 我们建议设置 CI，以确保软件包不会意外不完整等。
  • 软件包应保持与其依赖项的最新版本兼容。
  • 软件包作者/维护者旨在遵循 MAINTAINERS.md。

有关如何添加和测试软件包的完整详情，可在 此处 找到。

NOTE：从包上传到 Hackage 到可供 Github workflow action 检查上界，大约存在 30 分钟的延迟。如果拉取请求因使用旧版本而被标记为失败，请关闭并重新打开该 PR 以重新触发 CI 构建。

其他仓库

Stackage 项目由多个仓库组成。本仓库包含将纳入未来构建的包的元数据以及一些项目信息。此外，我们还有以下仓库：

好奇它们是如何组合在一起的？请参阅 Stackage 数据 流（略微过时）

构建包集合

通常只有由 stackage curator 团队运行的 stackage 构建服务器以及希望将 stackage 快照整合到操作系统发行版中的人员需要构建整个包集合。如果您有兴趣自行尝试，请查阅 curator 指南， 但请注意，这不是推荐的做法，您可能会遇到需要自行调试的问题。

处理

以下从高层级描述了处理的一系列步骤

每日构建

  1. 获取核心软件包列表
  2. 从受维护的软件包列表中获取构建约束
  3. 加载软件包索引
  4. 使用软件包的最新版本计算构建计划
  5. 写出包含完整构建计划的 YAML 文件
  6. 验证构建计划是否可以编译
  7. 执行构建

NOTE: Nightly 中那些长期阻碍其他软件包使用较新版本的软件包，最终会被禁用，具体取决于其影响程度，但最迟通常会在下一个主要 LTS 版本分支之后。

LTS

  1. 加载最近的构建计划
  2. 将构建计划转换为下一次构建的约束
  3. 从上述步骤 (3) 继续

常见问题

为什么 Stackage LTS 仍然使用旧版本的 GHC？

通常，从新的主要 ghc 版本发布到 Haskell 生态系统充分支持它，从而能够将其推送到新的稳定 Stackage 主要版本发布，需要几个月的时间。此外，ghc 的回归问题也可能阻碍 LTS 主要版本的发布。

对于次要 ghc 版本的滞后应该较少， 但仍需要额外的工作，并且通常会有些延迟 - 这也 允许在更新 LTS 之前进行一些社区测试。

为什么 Stackage 中的软件包版本比 Hackage 旧？

这个问题有几个答案：

  • 最简单的原因：你正在使用哪个 Stackage 快照？一旦快照创建完成，它将永久冻结。因此，如果你使用的是 nightly-2016-01-01，等到 2018 年时，它将会相当过时。
  • 如果你使用的是 LTS 快照：我们在首次创建 LTS 运行时锁定主要版本，因此后续的小版本不会获得必要的更新。例如，如果 LTS 6.0 中 foo 的版本为 1.2.3，而作者随后立即发布了 1.3.0 版本，且从未再发布任何 1.2.* 版本，那么在 LTS 6 系列中你将永远无法获得进一步的更新
  • 有时我们设置上限是因为其他包与依赖项的新版本存在兼容性问题。请打开 build-constraints 文件 并搜索 "Stackage upper bounds"
  • 内置包——即随 GHC 一起发布且无法升级的包，以及依赖这些包的包——被固定到 GHC 版本。常见的例子包括 containers 和 transformers。关于此主题的更多信息见 一篇 FP Complete 博客文章

LTS 构建的维护周期是多久？

我们仅保证同时维护一个 LTS 主要版本，并且该版本至少维护三个月。这是 最初提议的支持窗口， 自那以后未曾改变。

话虽如此，我们确实保留了并行维护多个 LTS 版本运行的能力，并且在 LTS 6 和 7 中确实这样做了。我们尚未改变对版本长期支持的保证，但正试图将边界稍微推得更远一些。

Stackage 快照的发布时间是什么时候？

Stackage Nightly 和 LTS 并非在固定的时间发布，它们会在 Stackage 构建服务器上的构建完成，且最新构建的 haddocks 同步完成后，推送到 stackage.org（以及元数据推送到 stackage-snapshots github 仓库）。具体时间因包更新的构建时间、版本约束破坏、新包添加的问题以及其他构建问题等因素而差异很大。有些日子可能不会发生发布。LTS 发布通常发生在周末或一周的初段。

在哪里获取有关上传包的帮助？

请在 Haskell Foundation Slack 的 #stackage 频道提问， 或针对上传该包的 PR 打开 issue 或发表评论。