随着 2020 年接近尾声，核心团队认为回顾一下我们社区今年取得的一些重大成就将会很有趣。

社区的许多成员公开和私下地提出了关于 Anaconda 新的服务条款 (TOS) 对 anaconda.com 的影响的问题。首先，我们理解您的担忧。我们想稍微解释一下 conda-forge 的工作原理、TOS 变更如何影响我们和 conda-forge 用户，以及我们社区未来的计划。

一个新的平台 osx-arm64 已被添加到 conda-forge 的构建矩阵中。osx-arm64 软件包构建为在即将推出的 macOS arm64 处理器（以 Apple Silicon 名义销售）上运行。此平台的安装程序可以在这里找到。

摘要：依赖于底层库的特定版本号可能过于不准确，并可能在上游库发展和变化时导致头痛。需要更详细的方法。在这篇文章中，我概述了当前和潜在的工作，旨在基于 API 和库的动态锁定，更全面地检查需求。

虽然 R 4.0 迁移在功能上已经完成很长时间了，但最近 r-java 及其依赖项的迁移提供了一个很好的机会来回顾 conda-forge 中大规模迁移的技术问题以及我们如何解决这些问题。

摘要：​

对 conda-forge 以及如何以可持续的方式扩展它有一些想法吗？加入我们这个虚拟的“鸟类同飞”讨论，我们将讨论维护、痛点、conda-forge 内的机会。欢迎所有人，我们尤其欢迎新的观点和意见！

最近我一直在思考运营风险（op. risk）。运营风险源于流程的失败，例如缺少电子邮件，或自动化软件系统运行不正常。许多商业机构都对最小化运营风险感兴趣，因为它是一种不产生价值的风险，而不是与投资相关的风险。这也是我在 Lab49 的工作中思考的事情，我在那里是一名专注于金融机构的软件工程顾问。我认为 Conda-Forge 也有一个很好的类比，即使我们不是商业机构。在这种情况下，我们承担的风险不是潜在的收入损失，而是用户和维护人员因错误和糟糕的用户体验而产生的挫败感。在这篇文章中，我探讨了 Conda-Forge 运营风险的三个主要来源：自动化、自上而下的控制和自助服务结构。

conda-forge 现在支持 PyPy3.6 作为 conda 环境中的 python 解释器

支持的平台有：

• Linux-x86_64 (glibc 2.12 或更新版本)
• OSX-x86_64 (OSX 10.9 或更新版本)
• Linux-aarch64 (glibc 2.17 或更新版本)
• Linux-ppc64le (glibc 2.17 或更新版本)

Skeletonr 的主要目标是征服 Grayskull。

简介​

玩笑归玩笑，新项目 grayskull 的创建目的是生成更好的 Conda 配方，以便能够正确打包在不同渠道（如 PyPI、CRAN、Conan、GitHub 注册表、GitHub 存储库等）中可用的项目。最重要的是，Grayskull 也在开发中，以帮助 conda-forge 更新配方。

conda-forge “autotick” 机器人是 conda-forge 基础设施的关键部分。它通过将版本更新推送到底层软件并实现软件包从一个依赖项到另一个依赖项的大规模迁移（例如，Python 3.7 到 Python 3.8），从而实现 conda-forge 软件包的自动维护。随着 conda-forge 规模的增长，迄今为止已超过 9,000 个软件包，conda-forge 生态系统的自动维护将变得更加重要。