跳到主要內容

固定的依賴項

全域固定的套件​

維護大量具有不同需求的套件，會產生具有互斥依賴項的套件孤島的風險。 特別是廣泛使用的函式庫，若具有受限的版本相容性，會增加套件空間分散的風險。 透過將關鍵函式庫固定到 conda-forge 中所有套件共用的特定依賴項版本，我們可以避免我們的套件分散到不相容的孤島中。 以下段落簡要介紹了如何在 conda-forge 中實現這種全域版本固定。

目前全域固定套件的版本定義在位於 conda-forge-pinning feedstock 中的 conda_build_config.yaml 檔案中。 這些固定的版本代表 conda-forge 目前支援的 ABI，幾乎所有可用的套件都針對該版本建置。

當重新渲染發生時，conda-smithy 將使用 conda-build 渲染 recipe，並為每個 job 輸出組態檔，並將它們儲存在 .ci_support 資料夾中的 yaml 檔案中。 例如，每個作業系統、每個 python 版本等都有一個輸出組態檔。

這些輸出組態檔會被剝離為建置中使用的選項，因此 .ci_support 資料夾中組態檔的變更意味著那裡需要新的建置。

套件的固定由相同的組態檔和 conda-build 處理。 這表示套件不需要手動固定。

例如：

requirements:
  host:
    - gmp 6.1.*
  run:
    - gmp 6.1.*

應替換為

requirements:
  host:
    - gmp
  run:
    - gmp

當 gmp 有新的 ABI 版本（例如 7.0）時，conda-forge-pinning 將會更新。 使用 gmp 的套件重新渲染將會變更。 因此，要檢查 recipe 是否需要針對更新的固定重新建置，您只需要檢查套件是否需要重新渲染。

注意

NumPy 是個例外 (請參閱 針對 NumPy 建置)。

如果套件未在 conda-forge-pinning 中固定，則需要手動進行固定。 如果套件是具有 C/C++ API 的 C/C++ 函式庫，且該 API 被其他函式庫使用和連結，則該套件是添加到 conda-forge-pinning 的候選套件。 請在 conda-forge-pinning-feedstock 中開啟 issue 進行討論。

注意

如果 conda-forge-pinning 中的約束不夠嚴格，您可以透過手動將套件固定到版本來覆寫它們。 您可以透過在執行需求中加入 {{ pin_compatible('gmp', max_pin='x.x.x') }} 來使固定更嚴格。

注意

如果您需要在極少數情況下移除固定，例如靜態連結套件，或者套件與 dlopen 而非連結一起使用，那麼您可以執行以下操作：

build:
  ignore_run_exports:
    - gmp

在 conda 文件中，有關於此固定方案的額外文件。

指定 run_exports​

run_exports 功能可用於指定與建置版本 ABI 相容的版本。 這提高了可選擇套件的彈性，而不會因不相容性而導致中斷。

依賴具有 run_exports 套件的套件可以選擇使用 build/ignore_run_exports 鍵來覆寫此行為。

注意

始終不完全清楚給定套件將如何使用。 例如，numpy 可以用作 python 套件，並且它也有一個可以連結的 C 函式庫。 前者的用法不需要 run_exports，但後者需要。

在這種情況下，將套件拆分為不同的 meta 套件可能是有利的，這些 meta 套件可以共享一個包含實際檔案的共同父套件，但每個 meta 套件定義不同的固定行為。 Anaconda 對 numpy 執行此操作（請參閱 recipe）。

一般概念是，當套件針對 C 介面建置時（即它需要相容性邊界），應該使用 numpy-devel 套件，而當套件僅使用 python 介面時，應該使用 numpy 套件。

一般來說，沒有必要拆分套件。 在 conda-forge 中，我們僅在它能大幅減少套件大小，或者當它有助於移除否則將不必要地包含的依賴項時才建議這樣做。

全域固定和 run_exports 是同一枚硬幣的兩面。 如果存在 ABI 中斷（由 run_exports 確定），則可能需要更新全域固定。 conda-forge 可能會跳過該 ABI。 一旦透過 migration yaml 更新固定，所有連結的套件都會重建。

更新套件固定​

變更全域固定需要重新渲染所有依賴於具有已變更固定的套件。 手動執行此操作可能很繁瑣，尤其是在涉及許多套件時。 Migrator 用於自動為 conda-forge 中受影響的套件產生 pull request。

通常，bot 會自動產生這些 migration。 但是，當首次進行或新增固定時，可能需要手動新增一個。 若要執行此操作，請按照以下步驟操作

  1. 透過複製 conda-forge/conda-forge-pinning 儲存庫中的 example.exyaml 來建立新的 migration yaml。
  2. 變更 migration yaml 以反映要 migration 的套件和版本
  3. 編寫 migrator 以傳播固定變更。
  4. 將變更作為 PR 提案提交到 conda-forge/conda-forge-pinning-feedstock。
  5. 一旦接受，migration 將開始。 可以在 https://conda-forge.dev.org.tw/status 監控 migration 狀態。
  6. migration 完成後，可以向 conda-forge/conda-forge-pinning-feedstock 發出新的 PR 以
    • 移除已完成 migration 的 migrator yaml
    • 如果套件的版本固定在全域 conda_build_config.yaml 中，則此 PR 也應該
      • 更新 conda_build_config.yaml 中的版本
      • 將 meta.yaml 中的版本 bump 到目前日期

migration yaml 如何設定的詳細資訊在 範例 和 此處 的文件中提供。