跳到主要内容

Clang 现在可用作所有平台的编译器

我们每个平台的编译器堆栈通常使用该平台的“默认”编译器，例如，请参阅此处。

实际上，这意味着

c_compiler:
  - gcc         # [linux]
  - clang       # [osx]
  - vs2019      # [win]
cxx_compiler:
  - gxx         # [linux]
  - clangxx     # [osx]
  - vs2019      # [win]

是 C/C++ 编译器的唯一可能选择。

最近，我们完成了添加初步支持 clang / clangxx 作为 C/C++ 编译器的功能，也适用于 Linux 和 Windows，从 clang 18 开始。这仍然非常新，因此可能会出现错误，除非有令人信服的理由，否则我们要求不要更改 feedstock 上的默认编译器。

无论如何，现在可以在 recipe/conda_build_config.yaml 中使用以下配置（请注意缺少平台选择器）

c_compiler:
  - clang
c_compiler_version:
  - 18
cxx_compiler:
  - clangxx
cxx_compiler_version:
  - 18

新的 conda-forge.org

您可能已经注意到，在过去的几个月中，我们一直在更改 conda-forge.org 网站的不同部分。阅读更多内容以了解我们更改了什么、它是如何工作的以及如何贡献。

stdlib("c") 的即将到来的迁移

几乎从 conda-forge 成立之初，我们的 C 标准库 ("stdlib") 的基线版本就没有改变。这个库带来额外的复杂性，因为它是操作系统的基本组成部分，也是 conda/mamba/etc. 无法安全发布的少数东西之一。

随着生态系统的发展和许多软件包开始需要更新的基线版本，我们需要在某个时候跟进。但是，为了避免破坏旧系统上的用户，我们需要建立基础设施，以便我们的软件包具有足够准确的元数据，以便 conda 可以避免在旧系统上安装需要更新 stdlib 的软件包。

在 conda-forge 利益相关者之间的多次讨论之后，我们达成的解决方案是引入一个新的 Jinja2 函数 {{ stdlib("c") }}，它反映了给定的 recipe 需要 C stdlib。使这种关系明确化将使正确反映每个 feedstock 以及我们的全局固定中对较新 stdlib 版本的需求变得容易。

到目前为止，stdlib 是作为编译器堆栈的一部分隐式处理的。为了使这种转换发生，我们需要将此函数引入到基本上所有编译的 recipe 中。这将分阶段完成，首先进行一次迁移，然后附加到 conda-forge 中所有正在进行的迁移。

piggyback 迁移器的逻辑试图正确处理大多数场景，但不可能涵盖所有极端情况。至于所有 feedstock 维护者都可以独立应用的一些通用规则

  • 如果 feedstock 在 build 部分中使用 - {{ compiler(...) }} jinja，请在 build 环境中添加一行 - {{ stdlib("c") }}。
  • 如果 feedstock 使用 - sysroot_linux-64 2.17 # [linux64]（或变体），请删除此行并将以下内容添加到您的 conda_build_config.yaml
    c_stdlib_version:              # [linux]
      - 2.17                       # [linux]
  • 如果 feedstock 在 conda_build_config.yaml 中设置了 MACOSX_DEPLOYMENT_TARGET，例如对于 x86_64 设置为 10.13，请将该部分替换为以下内容（请注意，这不适用于 MACOSX_SDK_VERSION！）
    c_stdlib_version:              # [osx and x86_64]
      - 10.13                      # [osx and x86_64]
  • 在 meta.yaml 中，您可以删除任何 - __glibc >=2.17 或 - __osx >={{ MACOSX_DEPLOYMENT_TARGET }} # [osx and x86_64] 的变体，因为从今以后将通过 - {{ stdlib("c") }} 处理。

应用上述任何更改后，应重新渲染 feedstock。

随着这些机制开始推出，我们还将更新 conda-forge 知识库中的维护者文档。有关更多详细信息，请参阅此问题。

在 2024 年 4 月 22 日放弃 CUDA 11.2

Conda-forge 正在停止对 CUDA 11.2 的支持。

CUDA 11 系列的最新版本是 CUDA 11.8。目前，conda-forge 已很好地支持 CUDA 11.8+。这是运行广泛的迁移工作以将 conda-forge feedstock 升级到较新 CUDA 版本的结果。

CUDA 11.8 软件包可以安装并在 CUDA 11.2 支持的同一硬件上运行。此外，CUDA 11.8 软件包还针对较新硬件进行了优化，而 CUDA 11.2 软件包则没有。因此，用户升级到 CUDA 11.8 是有好处的。

极少数似乎无人维护的 feedstock 尚未迁移。已在这些 feedstock 上提出问题，以使维护者了解此弃用计划。在它们更新之前，用户仍然可以安装他们之前生成的 CUDA 11.2 软件包。这些应该继续工作。但是，如果不更新到 CUDA 11.8，将无法重建这些软件包。

要将较旧的 feedstock 升级到 CUDA 11.8，只需重新渲染即可。如果 recipe 有 skip 或其他逻辑阻止这种情况发生，只需删除此逻辑并重新渲染以添加 CUDA 11.8。

发送此日期是为了确保维护者有整整一周的工作时间来完成任何剩余的更新，以迁移到 CUDA 11.8+。在 2024 年 5 月，NVIDIA 计划删除 conda-forge 一直用于构建 CUDA 11.2 的 CUDA 11.2 Docker 镜像。因此，conda-forge 将无法更新 CUDA 11.2 Docker 镜像，这将使维护变得更加困难。鼓励 Feedstock 维护者在那之前更新（如果他们尚未这样做）。

Rust 1.75 需要设置更新的 MACOSX_DEPLOYMENT_TARGET

随着 rust 1.75 的发布，我们现在要求将最小 MACOSX_DEPLOYMENT_TARGET 设置为至少 10.12。您可以通过将以下内容附加到 recipe/conda_build_config.yaml 来完成此操作

c_stdlib_version:       # [osx and x86]
  - '10.12'             # [osx and x86]

并在您的编译器 jinja 旁边添加 {{ stdlib("c") }} 作为构建依赖项

  build:
    - {{ compiler("rust") }}
    - {{ stdlib("c") }}

注意：此条目在 2024 年 4 月更新，以反映用于设置 MACOSX_DEPLOYMENT_TARGET 的新基础设施，请参阅此处。

Python 3.12 迁移和 Python 3.11 默认

随着 Python 3.12 版本的临近，我们已经开始为其重建软件包。尽管尚未发布官方的 Python 3.12 版本，但它的候选版本将具有相同的 ABI。因此，使用候选版本构建的软件包可以安全地用于以后的官方版本。为了支持在 conda-forge 上重建软件包，同时确保 Python 候选版本不会最终出现在最终用户的解决方案中，我们已将 Python 3.12.0rc2 和 rc3 构建上传到 conda-forge/label/python_rc 频道。python312 迁移在 feedstock 构建中将此频道添加到 Python 3.12 矩阵条目中。在 Python 3.12 官方发布时，我们将调整迁移并再次删除该频道。然后（在重新渲染时），feedstock 将仅再次使用主频道。

总的来说，这种方法使我们能够在 Python 3.12 官方发布当天就为各种软件包提供 Python 3.12。同时，我们已停止 Python 3.11 迁移，并将其添加到 conda-forge 上的默认 Python 版本列表中。

将最低 MacOS 版本提升至 10.13

我们将把最低 MacOS 版本从 10.9（于 2013 年 10 月发布，自 2016 年 12 月起停止生命周期）提升至 10.13（于 2017 年 9 月发布，自 2020 年 12 月起停止生命周期）。我们设法支持 10.9 这么长时间的主要原因是，conda-forge 能够为 OSX 运送最新的 C++ 标准库 libcxx，取代系统上 MacOS SDK 中存在的旧版本（至少从各个 conda 环境的角度来看）。

但是，生态系统中的几个核心软件包现在需要至少 10.13（或很快就需要），我们无法规避这种情况。这些软件包包括 libcxx，从版本 17.0 开始。此更改不会影响已发布的工件，但在不久的将来，OSX 的所有新构建都将需要至少 10.13。此约束将通过 __osx 虚拟软件包实现，但我们将如何实现这一目标的细节仍在制定中。只有 4.8.0 或更高版本的 conda 具有此虚拟软件包。如果您使用的系统 MacOS 版本低于 10.13 并且使用的 conda 版本低于 4.8.0，则需要将 conda 升级到至少 4.8.0 或将系统升级到至少 MacOS 10.13。

CentOS 6 的生命周期结束

您可能知道，我们已多次推迟弃用我们的 CentOS 6 构建系统 linux64 平台。我们现在已将正式弃用日期设置为 2024 年 6 月 30 日。此日期与 RedHat 为 RHEL 6 提供的扩展生命周期支持结束日期相符。在此日期之后，我们默认针对 CentOS 7 构建 linux64 的软件包。