概要：我们对 Docker 镜像和构建时间 GLIBC 选择进行了一些更新。

1. 我们已更新我们的默认 Docker 镜像以基于 alma9
2. 现在可以更轻松地覆盖 c_stdlib_version (特别是对于启用 CUDA 的 feedstock)，尽管我们的基线 2.17 没有改变。
3. 在必要时，您可以通过设置 os_version: ... (见下文) 更容易地切换镜像。
4. 我们已整合我们的镜像名称以遵循一致的模式

linux-anvil-{x86_64,aarch64,ppc64le}:{cos7,alma8,alma9}

一般来说，在绝大多数情况下，不需要覆盖 docker-image，但如果您需要这样做，您可以将以下内容添加到 conda-forge.yml

os_version:             # just to demo different values;
  linux_64: cos7        # whenever possible, please use
  linux_aarch64: alma8  # homogeneous distro versions
  linux_ppc64le: alma9  # across platforms

我们将逐步迁移 conda-forge 以使用每个提供商的唯一 feedstock 令牌。Feedstock 令牌用于允许维护者将软件包从我们的暂存区复制到主要的 conda-forge 频道。此更改将提高我们的安全态势，并帮助我们限制任何泄露令牌的影响。在此迁移过程中，我们还将使用新实施的 feedstock 令牌过期时间，以避免令牌更改和正在运行的构建之间的竞争条件。

核心团队已决定更改核心会议发生的时间，以适应更多不同时区的参与者。它仍将每两周的星期三举行一次，但从下周三，2024 年 11 月 13 日开始，它将在 UTC 时间 17:00-18:00 和 UTC 时间 14:00-15:00 之间交替进行。

为了清晰起见，以下是接下来的日期

• 2024 年 11 月 13 日，UTC 时间 17:00
• 2024 年 11 月 27 日，UTC 时间 14:00
• 2024 年 12 月 11 日，UTC 时间 17:00
• 2024 年 12 月 25 日，UTC 时间 14:00
• 2025 年 1 月 8 日，UTC 时间 17:00
• ... 等等。

新的日历现在可在“社区 > 会议”部分找到，以帮助查找日期。

两周前，我们对 CFEP-23 发起了投票，以决定是否将我们的 Element/Matrix 聊天室迁移到 Zulip。

此投票已通过，现在我们正在打开我们 Zulip 实例的大门：https://conda-forge.zulipchat.com/。请注册以保持联系！

根据 CFEP-23 (阅读它以获取更多详细信息)，这意味着我们将停止使用我们的 Element 聊天室。相反，所有聊天活动将在 Zulip 中继续进行。

我们已更改我们的 feedstock 输出验证程序。我们将不再自动将新软件包添加到现有 feedstock (例如，当添加新输出时)，而是要求维护者提交 PR，通过我们的 admin-requests 存储库添加新输出。通过 staged-recipes 创建的新 feedstock 将自动添加其输出。如果您维护的 feedstock 定期添加新输出 (例如，llvmdev 具有 libllvm18、libllvm19 等)，您可以使用 admin-requsts 存储库添加一个 glob 模式，该模式与您新输出的模式匹配。我们使用 Python fnmatch 模块测试这些模式与来自 feedstock 的新输出。来自 feedstock 的与 glob 模式匹配的输出将自动添加。有关软件包输出验证的更多详细信息，请参阅我们的文档。

近两年来，我们一直倾向于使用 python-build 作为 PyPA build 项目的包名，而不是 build。实际上，conda-forge 上的 build feedstock 已经被存档，并且没有更新版本。为了完成这个过渡，我们将把所有现有的 build 包标记为损坏，提供更详细的 linter 提示，并关闭我们一直用来帮助迁移 feedstocks 的基础设施。任何问题或意见都可以在GitHub issue 中提出。

从 Python 3.13 开始，pip 将不再默认将 setuptools 和 wheel 作为依赖项。虽然在 conda-forge 启动时 (8 年多以前!) 这个默认设置是有意义的，但随着 Python 打包构建后端 (例如，flit、poetry、hatchling 等) 的出现，这个默认设置不再正确。相反，如果您需要 wheel 和/或 setuptools，您需要在配方的 host 部分显式指定它们。最初，Python 3.13 之前的 Python 版本的 pip 将不受影响。但是，在 Python 3.13 迁移完成后，我们将从所有 Python 版本的 pip 中删除这些依赖项。关注 GitHub issue #2252 以获取更多信息和更新。

概要：我们计划在几周内从 conda-forge feedstock 配方中移除 PyPy (因此停止为 PyPy 构建软件包的新版本)，除非有足够大的兴趣来证明继续维护工作是合理的。

随着 Miniforge 23.3.1 版本的发布，Miniforge 和 Mambaforge 安装程序变得基本相同。两者之间唯一的区别是它们的名称，以及随后的默认安装目录。

维护两个安装程序给我们的支持基础设施增加了不必要的负担，并在最终用户中造成了混乱。因此，去年我们决定不鼓励使用 Mambaforge，而倾向于使用 Miniforge。

一年后，我们想正式停止 Mambaforge。鼓励所有用户切换到 Miniforge。请记住它们包含相同的软件包，因此唯一的区别是默认安装目录。

弃用过程将大致遵循此日历

• 2024 年 8 月：Mambaforge 安装程序将警告有关弃用的信息，并使用户等待 30 秒才能继续。
• 2024 年 10 月：Mambaforge 安装程序将在几个预先指定的日期范围内拒绝安装 (即，“brownouts”)，以鼓励用户切换到 Miniforge。这些日期是
  • 2024 年 10 月每两周一次 (2024-10-01, 2024-10-15)
  • 2024 年 11 月每十天一次 (2024-11-01, 2024-11-10, 2024-11-20, 2024-11-30)
  • 2024 年 12 月每五天一次 (2024-12-05, 2024-12-10, 2024-12-15, 2024-12-20, 2024-12-25, 2024-12-30, 2024-12-31)
• 2025 年 1 月：Mambaforge 安装程序将停止构建和分发。

为了准备 NumPy 2 发布，我们已经开始迁移所有在构建期间 (因此在 requirements/host 中) 依赖于 numpy 的 conda-forge 软件包。迁移状态在我们的状态页面上跟踪。可以在那里找到特定软件包的状态。维护者更新软件包的具体建议可以在迁移 PR 本身中找到。如果您有任何问题，请通过常用渠道联系。