套件的生命週期
conda-forge 實作了一套特定的工作流程，用於建置、發布和維護 conda 套件。然而，對於任何 conda 套件解決方案，核心概念都是相同的。
關於 conda 套件的一般概念
conda 套件是基於 conda 配方 建置的，配方包含一個元數據檔案（如 meta.yaml 或 recipe.yaml），以及可選的支援腳本和數據。建置工具（通常是 conda-build 或 rattler-build）會讀取配方並產生一個或多個套件（在不同情境下也稱為輸出和/或產物）。
雖然您可以自行發布產物，但 conda 套件通常會上傳到 conda 頻道，該頻道託管在如 Anaconda.org 等伺服器上。此頻道伺服器會處理所有上傳的套件，並將套件中包含的元數據彙整到每個平台或 subdir 的單個 repodata.json 檔案中。例如，以下是適用於 Linux x64 系統的 conda-forge repodata 子集：current_repodata.json。
這些是當使用者輸入 conda install ... 或類似命令時，conda 客戶端會提取的元數據檔案。解析器將處理所有元數據，並為使用者提供最合適的套件選擇，然後將這些套件下載、解壓縮並連結到目標 conda 環境中。
發布後特性
對於大多數套件而言，以上段落已足以描述其生命週期。然而，conda 生態系統中採用的 repodata 優先方法，允許在發布後階段提供一些獨特的功能。
對於像 conda-forge 這樣的大量頻道，Anaconda.org 通過 CDN 網路傳輸產物以加快存取速度。CDN 網路會定期與頻道同步。因此，套件在發布後約 15 分鐘即可用於安裝。
這種 repodata 優先方法提供了一個獨特的機會來後處理 repodata 檔案。這樣一來，我們就可以在不重建套件的情況下修復元數據問題。請注意，這些變更不會傳播回套件中包含的元數據。
Anaconda.org 還提供了頻道標籤的概念（channel labels），實際上其行為類似於子頻道。預設標籤為 main。當新增標籤時，套件也會在子頻道 <channel>/label/<label> 中顯示。例如，上傳到 conda-forge 並標記為 test 和 main 的套件將在 conda-forge 頻道中可用，也會在 conda-forge/label/test 子頻道中可用。
conda-forge 上的生命週期
任何人都可以於自己的電腦上執行 conda-build，並手動將他們的套件上傳到 Anaconda.org。然而，這種方法存在一些問題
- 它不利於協作。
- 過程中缺乏透明度。
- 再現性取決於系統。
- 無法保證跨套件的相容性。
- 它無法良好擴展到少數套件之外。
在 conda-forge 上，大多數套件是使用公共 CI 服務建置的，並由成千上萬的志願者維護，這需要以不同的方式來解決問題，以保證對權限的細粒度控制、獨立的專案管理和自動化批次更新。
主要概念是每個 conda 配方都由一個單獨的 GitHub 儲存庫處理。這些儲存庫在 conda-forge 中被稱為 feedstock，託管使用者貢獻的 conda 配方，以及幾個自動產生的必要腳本、設定檔和 CI 管線，以建置和匯出 conda 產物。在此設定下，當需要發布全域變更或修復時，conda-forge 機器人可以遍歷 conda-forge 儲存庫，以根據需要重新產生和更新 feedstock。
若要獲得 conda-forge feedstock，貢獻者必須先將其配方提交至 staged-recipes 儲存庫以供審查。一旦審查並批准，PR 就會合併到 main，這會觸發 feedstock 的建立。
在接受對 conda-forge 組織的邀請後，提交貢獻者將被授予對該儲存庫的提交權限。屆時，feedstock 建立機制 將會向必要的 CI 服務註冊新的儲存庫，並使用提交的配方以及支援腳本、設定檔和 CI 管線來填充其內容。
這些管線將處理初始提交，以產生 conda 產物並將其上傳到 cf-staging 頻道。任何後續推送至 main（例如，合併的 PR）或其他啟用的分支都將經歷相同的過程。
對於現有的 feedstock，conda-forge 機器人通常會針對新的專案發布或維護任務發送自動化的 PR。您可以在自動化與機器人中找到更多詳細資訊。
驗證伺服器將偵測 cf-staging 上的新上傳內容，並對這些產物執行一些檢查。如果成功，產物將隨後被複製到實際的 conda-forge 頻道。
此時，頻道伺服器將處理新套件的內容，以檢索其元數據並更新 repodata 檔案。在下一個 CDN 同步週期中，產物將被分發到傳遞網路以加快存取速度。驗證和 CDN 同步通常在 CI 在 main 上通過後約需 15 分鐘。從這一刻起，使用者可以從 CLI 安裝新的套件。
發布後特性
在理想情況下，這將是生命週期的結束。然而，在某些情況下，有些套件會經歷一些發布後階段。
如果發現套件元數據錯誤或過時，則可以在不重建套件的情況下對其進行修改。頻道伺服器可以直接將修補程式應用於 repodata 檔案，方法是透過 conda-forge-repodata-patches 中發布的指令，這些指令每週處理一次。
有時，已發布的套件存在一些問題，這些問題無法通過 repodata 修補程式來修正（例如，函式庫建置錯誤且發生區段錯誤）。在這些情況下，可以通過將套件標記為 broken 來使其退役。這是通過 admin-requests 儲存庫 完成的。作為 CDN 驅動的元數據修補的一部分，標記為 broken 的套件不包含在最終的 repodata 索引中。但是，它們仍然可以通過直接 URL 存取來使用。這允許組織從正常的、解析器驅動的安裝中退役套件，而不會損害鎖定檔案提供的再現性。
最後，專案可能已達到不再需要或預期進一步更新的狀態（例如，它已被一個新專案取代）。如果維護者願意，可以將這些 feedstock 存檔並標記為唯讀，這也是通過 admin-requests 完成的。
階段摘要
這些階段是 conda-forge 文件中的關鍵概念。當您查看文件的其餘部分時，隨時可以參考此列表。
- 初步提交至
staged-recipes - Feedstock 變更
- A. 儲存庫初始化
- B. 自動化維護更新
- C. 使用者提交的 PR
- 套件建置
- 套件驗證
- 套件發布
- 發布後
- A. Repodata 修補程式
- B. 將套件標記為損壞
- C. 封存 feedstock
如果您想閱讀更多關於這些階段背後的基礎設施詳細資訊，請考慮閱讀我們的基礎設施指南。