跳到主要内容

固定的依赖项

全局固定的软件包​

维护大量具有不同需求的软件包集合，存在产生具有互斥依赖项的软件包孤岛的风险。特别是广泛使用的具有受限版本兼容性的库，增加了软件包空间分裂的风险。通过将关键库固定到 conda-forge 中所有软件包共享的特定依赖项版本，我们避免了软件包在不兼容孤岛中的分裂。以下段落简要介绍了全局版本固定在 conda-forge 中是如何实现的。

全局固定的软件包的当前版本在位于 conda-forge-pinning feedstock 中的 conda_build_config.yaml 文件中定义。这些固定的版本代表 conda-forge 当前支持的 ABI，几乎所有可用的软件包都针对该版本构建。

当重新渲染发生时，conda-smithy 将使用 conda-build 渲染 recipe，并为每个作业输出配置文件，并将它们保存在 .ci_support 文件夹中的 yaml 文件中。例如，每个操作系统、每个 python 版本等都有一个输出配置文件。

这些输出配置文件被剥离为构建中使用的选项，因此 .ci_support 文件夹中配置文件中的更改意味着那里需要新的构建。

软件包的固定由相同的配置文件和 conda-build 处理。这意味着软件包不需要手动固定。

例如：

requirements:
  host:
    - gmp 6.1.*
  run:
    - gmp 6.1.*

应替换为

requirements:
  host:
    - gmp
  run:
    - gmp

当 gmp 有新的 ABI 版本（例如 7.0）时，conda-forge-pinning 将会更新。使用 gmp 的软件包的重新渲染将会改变。因此，要检查 recipe 是否需要为更新的固定重建，您只需要检查软件包是否需要重新渲染。

注意

NumPy 是一个例外（参见 构建 NumPy）。

如果软件包未在 conda-forge-pinning 中固定，则需要手动完成固定。如果软件包是带有 C/C++ API 的 C/C++ 库，并且该 API 被其他库使用和链接，则该软件包是添加到 conda-forge-pinning 的候选对象。请在 conda-forge-pinning-feedstock 中开启 issue 进行讨论。

注意

如果 conda-forge-pinning 中的约束不够严格，您可以通过手动将软件包固定到特定版本来覆盖它们。您可以通过将 {{ pin_compatible('gmp', max_pin='x.x.x') }} 添加到运行需求中来使固定更严格。

注意

如果需要在极少数情况下删除固定，例如静态链接软件包，或者软件包使用 dlopen 而不是链接，则可以这样做：

build:
  ignore_run_exports:
    - gmp

conda 文档中提供了有关此固定方案的更多文档，请参见 conda 文档。

指定 run_exports​

run_exports 功能可用于指定与构建版本 ABI 兼容的版本。这提高了可选择软件包的灵活性，而不会因不兼容性而导致崩溃。

依赖于具有 run_exports 的软件包的软件包可以选择使用 build/ignore_run_exports 键来覆盖此行为。

注意

并不总是完全清楚给定的软件包将如何使用。例如，numpy 可以用作 python 软件包，并且它还有一个可以链接到的 C 库。前者使用不需要 run_exports，但后者需要。

在这种情况下，将软件包拆分为不同的元软件包可能是有利的，这些元软件包可以共享包含实际文件的公共父软件包，但每个元软件包都定义不同的固定行为。Anaconda 对 numpy 这样做（请参阅 recipe）。

一般的想法是，当软件包针对 C 接口构建时（即它需要兼容性边界），应使用 numpy-devel 软件包，而当软件包仅使用 python 接口时，应使用 numpy 软件包。

一般来说，没有必要拆分软件包。在 conda-forge，我们仅在它能大大减小软件包大小，或者有助于删除原本不必要包含的依赖项时才建议这样做。

全局固定和 run_exports 是同一枚硬币的两面。如果存在 ABI 破坏（由 run_exports 确定），则可能需要更新全局固定。conda-forge 可能会跳过该 ABI。一旦通过迁移 yaml 更新了固定，那么所有链接的软件包都将重建。

更新软件包固定​

更改全局固定需要重新渲染所有依赖于具有更改固定的软件包的软件包。手动执行此操作可能很繁琐，尤其是在涉及许多软件包时。Migrators 用于自动为 conda-forge 中受影响的软件包生成 pull request。

通常，机器人会自动生成这些迁移。但是，当首次创建或添加固定时，可能需要手动添加一个。要执行此操作，请按照以下步骤操作

  1. 通过复制 example.exyaml 在 conda-forge/conda-forge-pinning 存储库中来创建新的迁移 yaml。
  2. 更改迁移 yaml 以反映要迁移的软件包和版本
  3. 编写一个 migrator 以传播固定更改。
  4. 将更改作为 PR 提交到 conda-forge/conda-forge-pinning-feedstock。
  5. 一旦接受，迁移将开始。可以在 https://forge.conda.org.cn/status 监控迁移状态。
  6. 迁移完成后，可以向 conda-forge/conda-forge-pinning-feedstock 发出新的 PR 以
    • 删除已完成迁移的 migrator yaml
    • 如果软件包的版本在全局 conda_build_config.yaml 中固定，则此 PR 也应该
      • 更新 conda_build_config.yaml 中的版本
      • 将 meta.yaml 中的版本提升到当前日期

有关如何设置迁移 yaml 的详细信息，请参见 此处的 示例 和 文档。