跳到主要内容

CEP 12 - 在 conda 渠道中提供 run_exports 元数据

标题在 conda 渠道中提供 run_exports 元数据
状态已接受
作者Jaime Rodríguez-Guerra <jrodriguez@quansight.com>
创建于2023 年 5 月 4 日
更新于2023 年 7 月 27 日
讨论https://github.com/conda-incubator/ceps/pull/51
实施NA

本文档中使用的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按照 RFC2119 中的描述进行解释，当且仅当它们全部以大写形式出现时，如此处所示。

摘要​

让 conda 渠道提供独立的 run_exports 元数据，与 repodata.json 并列。

动机​

构建基础设施（例如某些 conda-forge 机器人）使用 run_exports 来计算哪些软件包需要作为升级的一部分进行重建。目前，conda-forge 需要维护自己的 JSON 数据库，这涉及到下载和提取新的工件，因为它们变得可用：run_exports 元数据位于 .tar.bz2 和 .conda 文件内部。

由于 conda-index 已经处理软件包元数据以生成 repodata.json，因此同时生成 run_exports.json 并一起提供它们将是微不足道的。

优先级和在 pinning 解析过程中的作用​

此文件并非旨在替换软件包存档中已存在的 run_exports 元数据。它只是以更方便的方式呈现该信息。类似于 conda-build 的客户端可以自由使用存档中的 run_exports 元数据或 run_exports.json 中的元数据，因为它们必须是等效的。像 pin_run_as_build 这样的特殊键必须保持其行为，因为 run_exports.json 不会在 pinning 解析过程中添加新的优先级级别。同样，它是存档中已存在信息的等效来源。

这意味着 run_exports.json 绝不能被修补（就像对 repodata.json 所做的那样）。它必须始终反映存档中存在的元数据。

请注意，这仅适用于提供的 run_exports.json 文件。它不试图规范类似于 conda-build 的工具在环境创建时可以做什么。它们可能需要应用类似于 repodata 修补的修改到 run_exports 元数据，在 build、host 和 test 环境设置期间。如果证明修补 run_exports.json 对于正确的环境创建是必要的，那将是另一个 CEP 的主题，并且可能涉及模式版本的更改，以确保向后兼容性。

规范​

run_exports.json 的模式将在可能的情况下模仿 repodata.json 结构

  • info：关于平台、架构和 run_exports.json 模式版本的元数据。
  • packages：从 .tar.bz2 文件名到 run_exports 元数据 dict 的映射。
  • packages.conda：从 .conda 文件名到 run_exports 元数据 dict 的映射。

每个 run_exports 元数据 dict 可以包含以下字段；每个字段接受字符串列表（conda-build 规范）。

  • weak（弱）
  • strong（强）
  • weak_constrains（弱约束）
  • strong_constrains（强约束）
  • noarch
{
    "info": {
        "platform": "string",
        "arch": "string",
        "subdir": "string",
        "version": 0
    },
    "packages": {
        "package-version-build.tar.bz2": {
            "run_exports": {
                "noarch": [
                    "string",
                ],
                "strong": [
                    "string",
                ],
                "strong_constrains": [
                    "string",
                ],
                "weak": [
                    "string",
                ],
                "weak_constrains": [
                    "string",
                ],
            }
        }
    },
    "packages.conda": {
        "package-version-build.conda": {
            "run_exports": {
                "noarch": [
                    "string",
                ],
                "strong": [
                    "string",
                ],
                "strong_constrains": [
                    "string",
                ],
                "weak": [
                    "string",
                ],
                "weak_constrains": [
                    "string",
                ],
            }
        }
    }
}

如果软件包未定义 run_exports，则 packages 或 packages.conda 中的相应条目必须是空的 run_exports 项

{
    "info": {
        "platform": "string",
        "arch": "string",
        "subdir": "string",
        "version": 0
    },
    "packages": {
        "package-version-build.tar.bz2": {
            "run_exports": {}
        }
    },
    "packages.conda": {
        "package-version-build.conda": {
            "run_exports": {}
        }
    }
}

请参阅 run_exports.schema.json 中的验证模式草案。

向后兼容性​

这是一个新功能，因此无需担心向后兼容性。

替代方案​

我们可以维持现状，并要求下游基础设施维护自己的数据库。但是，这对他们来说是一个负担，并且生成此数据是微不足道的。

我们还考虑过将 run_exports 元数据添加到 repodata.json，但这有一些缺点

  • 这将需要扩展 repodata 模式，目前尚未正式标准化。
  • 这将增加已经很重的 repodata.json 文件的大小。
  • （类型化）repodata 解析器将需要更新以处理新字段。

最后，我们研究了 channeldata.json 元数据中已存在的 run_exports 元数据是否足够。但是，此元数据仅按版本（而不是构建版本）呈现，因此它是不充分和不完整的。更改 channeldata.json 模式以包含每个构建版本的 run_exports 元数据将是一个破坏性更改（例如，conda-build 的 --use-channeldata 选项）。

FAQ​

应包含哪些软件包？​

应包括未修补的 repodata.json（某些渠道中的 repodata_from_packages.json）文档中存在的所有软件包。

这会影响 repodata 获取的性能吗？​

只有软件包构建基础设施（例如 conda-forge 机器人）才需要获取此数据。生态系统的其余部分（例如 CLI conda 客户端）将不受影响。

参考文献​

所有 CEP 均明确采用 CC0 1.0 Universal。