在 2020 年即將結束之際，核心團隊認為回顧一下我們社群今年取得的一些重大成就將會很有趣。

社群的許多成員公開和私下提出了關於 Anaconda 新的 `anaconda.com` 服務條款 (TOS) 影響的問題。首先，我們理解您的擔憂。我們想稍微解釋一下 `conda-forge` 的運作方式、TOS 的變更如何影響我們和 `conda-forge` 使用者，以及我們社群未來的計畫。

conda-forge 的建置矩陣中新增了一個新的平台 `osx-arm64`。`osx-arm64` 套件旨在於即將推出的 macOS arm64 處理器（以 `Apple Silicon` 名義銷售）上執行。此平台的安裝程式可以在這裡找到。

重點摘要：依賴底層程式庫的特定版本號碼可能太過不精確，並且可能在上游程式庫演進和變更時導致頭痛問題。需要更詳細的方法。在這篇文章中，我概述了目前和潛在的工作，以基於 API 和程式庫的動態釘選來更完整地檢查需求。

雖然 R 4.0 的遷移在功能上已經完成很長一段時間了，但最近 `r-java` 及其依賴項的遷移提供了一個很好的機會來撰寫關於 `conda-forge` 中大規模遷移的技術問題以及我們如何解決這些問題的回顧。

摘要：​

對於 conda-forge 以及如何以永續的方式擴展它有一些想法嗎？加入我們這個線上 Birds of a Feather 討論，我們將在其中討論維護、痛點、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` 生態系統的自動維護將變得更加重要。