跳到主要內容

知識庫

使用 Github 程式碼搜尋尋找範例​

Github 的 程式碼搜尋 是一個非常實用的工具，可以在 conda-forge 中找到配方範例。您可以使用一些技巧來充分利用您的搜尋。

  • 將搜尋範圍限制在 org:conda-forge。
  • 將路徑限制為您想要的文件類型。這通常意味著
    • path:meta.yaml，用於主要的 metadata 文件。
    • path:recipe/*.sh，用於 Unix 建置腳本。
    • path:recipe/*.bat，用於 Windows 建置腳本。

就是這樣，透過這兩個修飾符，您可以完成很多工作！一些範例包括

設定您的瀏覽器以擁有搜尋捷徑

例如，在 Chrome 中，您可以前往 chrome://settings/searchEngines 並新增一個項目，內容如下：

  • 名稱： conda-forge 配方
  • 捷徑： cf
  • 網址： https://github.com/search?type=code&q=org%3Aconda-forge+%s

這樣一來，您只需輸入 cf your-search-here 即可進行超快速查詢！

使用 CMake​

CMake 可用於在 build.sh 或 bld.bat 腳本中建置更複雜的專案。

如果您正在使用 cmake，請務必將其設為 build 區段中的建置需求。您可能還需要包含 make 或 ninja，具體取決於您的平台和建置工具。在 Windows 上，您也可以使用 nmake 進行建置，但不需要明確包含。

requirements:
  build:
    - cmake
    - make  # [not win]
    - ninja  # [win]

對於使用 FindPython 模組的 CMake 專案，您可以透過傳遞 -DPython_EXECUTABLE="$PYTHON" (macOS 或 Linux) 或 -DPython_EXECUTABLE="%PYTHON%" (Windows) 作為命令列選項，來告知 CMake 要使用哪個 Python。較舊的 CMake 專案可能需要類似但略有不同的選項。

提示

別忘了，根據您使用的 CMake 模組，您必須使用不同的命令

或者，如果您仍然使用已棄用的 FindPythonLibs: -DPYTHON_EXECUTABLE=...。

一些可選但有用的 CMake 選項

  • -DCMAKE_BUILD_TYPE=Release 設定為發行版本建置。最好在初始 cmake 呼叫時完成此操作，因為某些套件會根據此旗標建構不同的建置組態。
  • -DCMAKE_INSTALL_PREFIX=$PREFIX 指定安裝位置。
  • -DCMAKE_INSTALL_LIBDIR=lib 函式庫將會安裝在 $PREFIX/lib 中，有時專案會安裝到 lib64 或類似位置，但在 conda-forge 上，我們將共享函式庫簡化地放在 lib 中。
  • -DBUILD_SHARED_LIBS=ON 指示 CMake 建置共享函式庫而不是靜態函式庫。
  • -DCMAKE_FIND_FRAMEWORK=NEVER 和 -DCMAKE_FIND_APPBUNDLE=NEVER 防止 CMake 使用系統範圍的 macOS 套件。
  • ${CMAKE_ARGS} 新增 conda-forge 內部定義的變數。這是啟用各種 conda-forge 增強功能所必需的，例如 CUDA 建置。

以下是一些基本的命令，供您開始使用。這些命令取決於您的原始碼佈局，並非旨在「按原樣」使用。

用於 build.sh (macOS/Linux) 的 CMake 行

cmake CMakeLists.txt -DPython3_EXECUTABLE="$PYTHON"
cmake --build . --config Release

用於 bld.bat (Windows) 的 CMake 行

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DPython3_EXECUTABLE="%PYTHON%"
if errorlevel 1 exit /b 1
cmake --build . --config Release
if errorlevel 1 exit /b 1

另請參閱下方 Windows 區段中的 bld.bat，以取得更多範例。

其他有用的 cmake 選項包括 -B<directory> 和 -S<directory>，用於指定建置和原始碼目錄。

從 autotools 建置轉移到 CMake 建置​

某些套件維護 autotools 建置和 cmake 建置。有些維護者想要切換到 cmake 建置，因為這樣可以輕鬆提供 Windows 建置。這些建置在很大程度上彼此不相容 ABI。以下是一些您應該檢查的事項：

  1. 檢查兩個函式庫在 Linux 上是否具有相同的 SONAME

    執行 readelf -d /path/to/lib.so

  2. 檢查兩個函式庫是否具有相同的安裝名稱，以及是否具有相同的相容性和目前版本。

    執行 otool -L /path/to/lib.dylib。第二行應該會提供您三個資訊

  3. 檢查兩個函式庫中的文件列表是否相同。

  4. 檢查您是否使用了與相同 autoconf 建置相同的選項。

  5. 檢查匯出的符號是否相同。

  6. 檢查額外的套件資訊是否保持不變，例如，是否提供了相同的 pkg-config 資訊。

Windows 上的特殊性​

本文檔介紹了在 Windows 上建置時的 conda-forge 和 conda-build 資訊與範例。

本機測試​

您應該知道的第一件事是，即使您沒有 Windows 機器，也可以在本機測試套件的 Windows 建置。 Microsoft 在 此網站 上提供了免費的官方 Windows 虛擬機器 (VM)。如果您不熟悉 VM 系統或安裝 Microsoft 的 VM 時遇到問題，請使用一般的網路搜尋來探索 — 雖然這些主題超出了本文檔的範圍，但在更廣泛的網際網路上有很多關於它們的討論。

若要引導 conda 環境並安裝 conda-build，請考慮使用 miniforge。

執行建置​

build-locally.py 腳本尚不支援 Windows (歡迎 PR！)。您可以使用 conda build recipe/ -m .ci_support/choose_your_config.yaml 作為目前的替代方案。

測試本機建置​

由於我們直接使用 conda-build 而不是 build-locally.py，因此我們可以使用 local 頻道

conda create -n my-new-env -c local my-package

關於原生程式碼的注意事項​

為了在 Windows 上編譯原生程式碼 (C、C++ 等)，您需要在您的 VM 上安裝 Microsoft 的 Visual C++ 建置工具。您必須安裝特定版本的這些工具 — 這是為了保持 Python 中使用的編譯函式庫之間的相容性，如 此 Python wiki 頁面 中所述。目前相關的版本是

  • 對於 Python 3.5–3.12+：Visual C++ 14.x

雖然您可以透過安裝完整 Visual Studio 開發環境的正確版本來取得這些工具，但您可以透過安裝獨立的「建置工具」套件來節省大量時間和頻寬。您可以從 Visual Studio 訂閱 取得它們。若要下載建置工具，您需要一個 Microsoft 帳戶。進入 Visual Studio 訂閱頁面後，您可能還需要加入 Dev Essentials 計劃。完成後，您可以點擊「下載」標籤並搜尋「Build Tools for Visual Studio 2022」。在 conda-forge 完全 遷移到 Visual Studio 2022 之前，您可能仍然需要安裝「Build Tools for Visual Studio 2019」才能在本機建置 feedstock。根據您的需求和可用的硬碟空間，您可以直接使用 Visual Studio Build Tools 2019 安裝程式 安裝 VC-2019，或者您可以使用 Visual Studio Build Tools 2022 安裝程式 安裝 VC-2022 和 VC-2019，並確保勾選「MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.29)」的可選方塊。

如果您需要更多資訊。請參考 關於 Windows 編譯器的 Python wiki 頁面。

簡單的基於 CMake 的 bld.bat​

某些專案提供 CMake 的 hooks 來建置專案。以下範例 bld.bat 文件示範了如何為此類專案建置傳統的 out-of-core 建置。

基於 CMake 的 bld.bat

setlocal EnableDelayedExpansion

:: Make a build folder and change to it.
mkdir build
cd build

:: Configure using the CMakeFiles
cmake -G "NMake Makefiles" ^
      -DCMAKE_INSTALL_PREFIX:PATH="%LIBRARY_PREFIX%" ^
      -DCMAKE_PREFIX_PATH:PATH="%LIBRARY_PREFIX%" ^
      -DCMAKE_BUILD_TYPE:STRING=Release ^
      ..
if errorlevel 1 exit 1

:: Build!
nmake
if errorlevel 1 exit 1

:: Install!
nmake install
if errorlevel 1 exit 1

以下 feedstock 是已部署此建置結構的範例

為不同的 VC 版本建置​

在 Windows 上，不同的 Visual C 版本具有不同的 ABI，因此需要為不同的 Visual C 版本建置套件。套件與它們建置時使用的 VC 版本相關聯，並且某些套件對 VC 版本有特定要求。例如，python 2.7 需要 vc 9，而 python 3.5 需要 vc 14。

使用 conda-build 3.x，使用 compiler jinja 語法時，vc 可以用作選擇器。

requirements:
  build:
    - {{ compiler('cxx') }}

若要跳過使用特定 vc 版本進行建置，請新增 skip 語句。

build:
    skip: true  # [win and vc<14]

requirements:
  build:
    - {{ compiler('cxx') }}

使用 vs2022​

在 recipe/conda_build_config.yaml 文件中

c_compiler:    # [win]
- vs2022       # [win]
cxx_compiler:  # [win]
- vs2022       # [win]

您可以查看 此 PR 中的變更。

進行這些變更後，別忘了使用 conda-smithy 重新渲染 (若要手動重新渲染，請從命令列使用 conda smithy rerender)。

CMD/Batch 語法的提示與技巧​

Windows 配方預設依賴 CMD/Batch 腳本 (.bat)。 Batch 語法與 Unix 上的 Bash 和其他 shell 略有不同，因此如果您不熟悉這種腳本語言，我們在此收集了一些提示來幫助您入門。

  • 先檢查您是否需要編寫 Batch 腳本！簡單的配方可能不需要 shell 特定的程式碼，並且可以用不可知的方式編寫。使用 meta.yaml 中的 build.script 項目 (請參閱 conda-build 文件)。此項目可以接受字串或字串列表 (每行一個)。
  • SS64 的 CMD 教學頁面 是關於 CMD/Batch 語法的任何類型問題的最佳資源。
  • 在 conda-forge 中搜尋現有的 .bat 腳本，並從範例中學習。請參閱此 所有 Batchfile 的範例查詢。
  • 您可以從 Microsoft 免費試用 Windows VM。設定一個具有您最喜歡的虛擬化解決方案的 VM 來偵錯您的 CMD 語法。網路上也有一些最小的模擬器，即使並非所有 CMD 功能都存在，它們也可能會讓您開始了解基礎知識。例如，這個 Windows 95 模擬器 具有或多或少還可以的 MS-DOS 提示字元。

特殊的相依性和套件​

編譯器​

編譯器是具有特殊語法的相依性，並且始終新增到 requirements/build。

目前支援五種編譯器

  • C
  • cxx
  • Fortran
  • Go
  • Rust

需要所有五個編譯器的套件將定義為

requirements:
  build:
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}
    - {{ compiler('fortran') }}
    - {{ compiler('go') }}
    - {{ compiler('rust') }}
注意

適當的編譯器執行階段套件將會自動新增到套件的執行階段需求中，因此無需指定 libgcc 或 libgfortran。關於 conda-build 3 如何處理編譯器的更多資訊，請參閱 conda 文件。

交叉編譯​

conda-forge 預設為在 Linux、macOS 和 Windows 上針對 x86_64 進行套件的原生建置，因為這是為預設 CI 執行器提供動力的架構。也支援其他架構，但不保證它們具有原生建置。在我們無法提供原生 CI 執行器的平台上，我們仍然可以求助於交叉編譯或模擬。

交叉編譯意味著為與執行建置過程的架構不同的架構建置套件。鑑於 x86_64 執行器的豐富性，最常見的交叉編譯設定將以 x86_64 執行器為目標，針對非 x86_64 架構。

交叉編譯術語通常區分兩種機器類型

  • 建置：執行建置過程的機器。
  • 主機：我們正在為其建置套件的機器。
注意

一些交叉編譯文件也可能區分第三種類型的機器，即目標機器。您可以在 此 Stack Overflow 問題 中閱讀更多相關資訊。就 conda-forge 而言，我們將認為目標機器與主機相同。

如何啟用交叉編譯​

交叉編譯設定取決於 build_platform 和 target_platform conda-build 變數

  • build_platform：conda-build 正在其上執行的平台，它定義了 $BUILD_PREFIX 中的 build 環境。
  • target_platform：套件將安裝在其上的平台。定義了 $PREFIX 中 host 環境的平台。預設為 build_platform 的值。

若要變更 target_platform 的值並啟用交叉編譯，您必須使用 conda-forge.yml 中的 build_platform 映射，然後 重新渲染 feedstock。這將產生適當的 CI 工作流程和 conda-build 輸入 metadata。另請參閱 test，了解如何在交叉編譯時跳過測試階段。如果需求 metadata 和建置腳本編寫正確，套件應該可以正常運作。但是，在某些情況下，它需要進行一些調整；請參閱以下範例，了解一些常見情況。

注意

build_platform 和 target_platform 變數作為環境變數在建置腳本 (例如 $build_platform) 中公開，並且也作為 Jinja 變數在 meta.yaml 選擇器 (例如 # [build_platform != target_platform]) 中公開。

除了這兩個變數之外，conda-forge 的自動化 (例如 conda-forge-ci-setup、編譯器啟動套件等) 還設定了一些其他環境變數，可以協助進行交叉編譯設定

  • CONDA_BUILD_CROSS_COMPILATION：當 build_platform 和 target_platform 不同時，設定為 1。
  • CONDA_TOOLCHAIN_BUILD：建置平台預期的 autoconf triplet。
  • CONDA_TOOLCHAIN_HOST：主機平台預期的 autoconf triplet。
  • CMAKE_ARGS：使用 CMake 進行交叉編譯所需的引數。在您的建置腳本中將其傳遞給 cmake。
  • MESON_ARGS：使用 Meson 進行交叉編譯所需的引數。在您的建置腳本中將其傳遞給 meson。請注意，也會自動為您建立 交叉建置定義文件。
  • CC_FOR_BUILD：以建置平台為目標的 C 編譯器。
  • CXX_FOR_BUILD：以建置平台為目標的 C++ 編譯器。
  • CROSSCOMPILING_EMULATOR：主機平台的 qemu 二進位文件的路徑。在交叉編譯時對於執行測試很有用。

這些都由版本 3 中引入的兩個主要 conda-build 功能支援

將需求放在 build 或 host 中​

經驗法則是

  • 如果它需要在建置期間執行，則放在 build 中。
  • 如果它需要在目標主機上可用，則放在 host 中。
  • 如果兩個條件都為真，則它屬於兩者。

但是，此規則有一些例外；最值得注意的是 Python 交叉編譯 (請參閱下文)。

交叉編譯範例​

套件需要在其配方中進行一些變更才能與交叉編譯相容。以下是一些範例。

使用 autotools 進行交叉編譯的簡單 C 函式庫可能如下所示

requirements:
  build:
    - {{ compiler("c") }}
    - make
    - pkg-config
    - gnuconfig

在建置腳本中，它需要更新設定文件並在交叉編譯時保護任何測試

# Get an updated config.sub and config.guess
cp $BUILD_PREFIX/share/gnuconfig/config.* .

# Skip ``make check`` when cross-compiling
if [[ "${CONDA_BUILD_CROSS_COMPILATION:-}" != "1" || "${CROSSCOMPILING_EMULATOR:-}" != "" ]]; then
  make check
fi

使用 CMake 進行交叉編譯的簡單 C++ 函式庫可能如下所示

requirements:
  build:
    - {{ compiler("cxx") }}
    - cmake
    - make

在建置腳本中，它需要更新 cmake 呼叫並在交叉編譯時保護任何測試

# Pass ``CMAKE_ARGS`` to ``cmake``
cmake ${CMAKE_ARGS} ..

# Skip ``ctest`` when cross-compiling
if [[ "${CONDA_BUILD_CROSS_COMPILATION:-}" != "1" || "${CROSSCOMPILING_EMULATOR:-}" != "" ]]; then
  ctest
fi

同樣地，使用 Meson，meta.yaml 需要

requirements:
  build:
    - {{ compiler("c") }}
    - {{ compiler("cxx") }}
    - meson
    - make

以及 build.sh 中的這個

# Pass ``MESON_ARGS`` to ``meson``
meson ${MESON_ARGS} builddir/

使用 Cython 和 NumPy C API 的簡單 Python 擴充功能看起來像這樣

requirements:
  build:
    - {{ compiler("c") }}
    - cross-python_{{ target_platform }}    # [build_platform != target_platform]
    - python                                # [build_platform != target_platform]
    - cython                                # [build_platform != target_platform]
    - numpy                                 # [build_platform != target_platform]
  host:
    - python
    - pip
    - cython
    - numpy
  run:
    - python
    - {{ pin_compatible("numpy") }}

使用 MPI 時，建置平台需要 openmpi，因為編譯器 wrappers 是二進位文件，但 mpich 不是必需的，因為編譯器 wrappers 是腳本 (請參閱 範例)

requirements:
  build:
    - {{ mpi }}                             # [build_platform != target_platform and mpi == "openmpi"]
  host:
    - {{ mpi }}
  run:
    - {{ mpi }}

在建置腳本中，openmpi 編譯器 wrappers 可以透過將環境變數 OPAL_PREFIX 設定為 $PREFIX 來使用 host 函式庫。

if [[ "$CONDA_BUILD_CROSS_COMPILATION" == "1" && "${mpi}" == "openmpi" ]]; then
  export OPAL_PREFIX="$PREFIX"
fi

在實際應用中，這種方法有更多變化。因此，這並非旨在詳盡無遺，而僅僅是提供一個起點和一些指南。請查看 其他配方以取得更多範例。

在使用 CMake 的交叉編譯 Python 套件中尋找 NumPy​

如果您正在使用 NumPy 和 CMake 建置 Python 擴充功能，並且希望它在交叉編譯中工作，您需要在建置腳本中將以下幾行程式碼前置到 CMake 呼叫中

Python_INCLUDE_DIR="$(python -c 'import sysconfig; print(sysconfig.get_path("include"))')"
Python_NumPy_INCLUDE_DIR="$(python -c 'import numpy;print(numpy.get_include())')"
CMAKE_ARGS="${CMAKE_ARGS} -DPython_EXECUTABLE:PATH=${PYTHON}"
CMAKE_ARGS="${CMAKE_ARGS} -DPython_INCLUDE_DIR:PATH=${Python_INCLUDE_DIR}"
CMAKE_ARGS="${CMAKE_ARGS} -DPython_NumPy_INCLUDE_DIR=${Python_NumPy_INCLUDE_DIR}"
CMAKE_ARGS="${CMAKE_ARGS} -DPython3_EXECUTABLE:PATH=${PYTHON}"
CMAKE_ARGS="${CMAKE_ARGS} -DPython3_INCLUDE_DIR:PATH=${Python_INCLUDE_DIR}"
CMAKE_ARGS="${CMAKE_ARGS} -DPython3_NumPy_INCLUDE_DIR=${Python_NumPy_INCLUDE_DIR}"

關於交叉編譯 Python 套件的詳細資訊​

交叉編譯 Python 套件比其他套件更複雜一些。主要痛點是我們需要一個可執行的 Python 直譯器 (即 build 中的 python)，該直譯器知道如何提供關於目標平台的準確資訊。由於這並未獲得官方支援，因此需要一系列的變通方法才能使其運作。請參閱 PEP720 或 此 issue 中的討論 以取得更多資訊。

實際上，對於 conda-forge，這導致 meta.yaml 中需要額外的兩個 metadata 位元

  • 在 build 需求中新增 cross-python_{{ target_platform }}，由 cross-python-feedstock 提供。這是 crossenv Python 直譯器的 wrapper，具有 一些啟動邏輯，用於調整一些 crossenv 變通方法，使其更適合 conda-build 設定。
  • 使用 [build_platform != target_platform] 選擇器將一些與 Python 相關的套件從 host 複製到 build
    • python 本身，以支援 crossenv。
    • 在建置套件時需要存在的非純 Python 套件 (即它們運送編譯函式庫)，例如 cython 和 numpy。

就 PEP720 而言，conda-forge 設定實作了「偽造目標環境」方法。更具體地說，這將導致在執行建置腳本之前進行以下變更

  • $BUILD_PREFIX/venv 中修改後的 crossenv 安裝，模擬 $PREFIX 的架構。
  • $BUILD_PREFIX/bin 中指向 crossenv 安裝的轉發器二進位文件。
  • 在 crossenv 安裝中公開 $BUILD_PREFIX site-packages 的符號連結，該安裝也包含在 $PYTHONPATH 中。
  • 將所有 $PREFIX site-packages 複製到 $BUILD_PREFIX (編譯函式庫除外)。

總而言之，這會產生一個設定，其中 conda-build 可以執行 $BUILD_PREFIX 架構的 python 直譯器，該直譯器可以看到 $PREFIX 中的套件 (編譯位元由 $BUILD_PREFIX 中對應的對等項目提供)，並充分模擬目標架構。

模擬建置​

當無法進行交叉編譯時，可以求助於模擬。這是一種使用虛擬機器 (QEMU) 來模擬目標平台的技術，這會產生顯著的開銷。但是，conda-build 會將目標平台視為原生平台，因此通常配方中幾乎不需要變更。

若要啟用模擬建置，您必須使用 conda-forge.yml 中的 provider 映射。此鍵將 build_platform 映射到將用於模擬平台的 provider。 conda-smithy 將知道如何偵測提供者是否原生支援該平台或是否需要模擬，並將調整適當的 CI 步驟以確保 QEMU 執行該過程。透過 重新渲染 feedstock 來確保變更已套用。

請注意，目前僅透過模擬支援 Linux 架構。

警告

模擬建置非常慢，並且會對 conda-forge CI 資源造成額外壓力。在可能的情況下，請考慮改用交叉編譯。僅將模擬建置作為最後手段。

模擬範例​

設定 conda-forge.yml 以模擬 linux-ppc64le，但對 linux-64 和 linux-aarch64 使用原生執行器。這是可行的，因為 Azure 原生不支援 linux-ppc64le，因此 conda-smithy 將新增 QEMU 步驟來模擬它。但是，linux-64 和 linux-aarch64 分別受到 Azure 和 Travis CI 的原生支援，因此不需要模擬。

provider:
  linux_aarch64: travis
  linux_ppc64le: azure
  linux_64: azure

Rust Nightly​

許多 rust 套件依賴 rust 編譯器的 nightly 版本。鑑於這種快速的發布節奏，conda-forge 尚未提取每個版本。相反，rust nightly 版本會根據需要提取到 conda-forge/rust-feedstock 的 dev 分支中。對於新版本，請在該 feedstock 上提交 issue。

若要在您的 feedstock 中啟用 rust nightly 編譯器，請依照上面的區段操作，然後在 conda_build_config.yaml 文件中新增 rust_dev 頻道

channel_sources:
  - conda-forge/label/rust_dev,conda-forge

核心相依性樹狀結構套件 (CDT)​

應避免使用 conda-forge 頻道外部的相依性 (請參閱 避免外部相依性)。但是，有一些例外情況

有些相依性非常接近系統，以至於它們未與 conda-forge 打包在一起。這些相依性必須透過核心相依性樹狀結構 (CDT) 套件來滿足。

CDT 套件由重新打包的 CentOS/AlmaLinux 二進位文件組成，這些二進位文件來自適當的版本，根據使用者選擇和平台，可以是 7、8 或 9。我們使用集中式 repo conda-forge/cdt-builds 來管理 CDT 套件的建置，而不是為它們產生 feedstock。(請注意，從歷史上看，我們確實使用過 feedstock，但這種做法已被棄用)。若要新增新的 CDT，請在 conda-forge/cdt-builds repo 上建立 PR。

為什麼 CDT 不好？​

  1. CDT 重新打包舊版本的函式庫。
  2. 因此，下游 conda 套件將不會使用套件中較新的功能，這些套件會檢查所建置函式庫的版本。例如：CentOS 7 打包函式庫中的 OpenGL 功能可用，但任何較新的功能都無法使用。
  3. 我們無法保證使用者系統提供的版本是否相容。我們只有 __glibc>=2.17 限制，並且我們假設 CentOS 7 的 GLIBC 下限及其對應的 CDT 下限是等效的。
  4. 我們無法保證使用者系統是否完全提供了該函式庫。

何時應使用 CDT？​

  1. 當函式庫使用系統特定的組態時。一些範例包括
    1. linux-pam：這是一個允許可插拔驗證模組的函式庫，這些模組的組態文件通常位於 /etc/pam.d 中。問題在於可插拔模組位於發行版特定的位置。例如：/usr/lib/x86_64-linux-gnu/security/。預設模組建置到 $CONDA_PREFIX/lib/security 中的 conda 套件中，但系統範圍組態的自訂模組安裝到 /usr/lib/x86_64-linux-gnu/security/ 中。因此，我們需要修補模組以同時查看兩者，但目錄 /usr/lib/x86_64-linux-gnu/security/ 是發行版特定的，並且難以偵測。
  2. 當 conda 打包的函式庫無法正常運作時。例如：新的 glibc 套件意味著我們將必須編輯所有 conda 套件二進位文件的 elf 直譯器。

有哪些好的範例？​

  1. OpenCL 載入器 (ocl-icd 以及 ocl-icd-system) 提供了一個 OpenCL 載入函式庫。此載入器會查找 $CONDA_PREFIX/etc/OpenCL/vendors 中指定的 OpenCL 實作。例如：Pocl 是一個 conda 打包的實作，可在 CPU 上執行 OpenCL。像是 NVIDIA OpenCL 或 ROCm OpenCL 等供應商特定的實作並非 conda 打包，因此我們必須依賴系統。透過安裝 ocl-icd-system，我們讓載入器能夠查找 /etc/OpenCL/vendors 中的設定，這是所有 Linux 發行版的設定目錄。這給了我們兩全其美的優勢。您不需要系統層級的套件來執行 OpenCL，因為我們有一個 conda 打包的安裝，但如果系統中有特定硬體加速的實作，我們也可以使用這些實作。

libGL​

請注意，依賴 OpenGL 和/或 libGL 的套件不應再使用 CDT。相反地，請使用來自 libglvnd-feedstock 的主機依賴項 libgl-devel。

requirements:
  host:
    - libgl-devel  # [linux]

其他 OpenGL API 變體，例如 libegl-devel、libgles-devel、libglx-devel 和 libopengl-devel 也可用，並且會自動新增非開發用的 run_exports 依賴項。

針對 NumPy 建置​

連結到 NumPy 的套件在依賴項章節中需要特殊處理。在 setup.py 中找到 numpy.get_include() 或在 .pyx 或 .pyd 檔案中找到 cimport 陳述式，都是套件連結到 NumPy 的明顯跡象。

在連結的情況下，您需要使用 pin_compatible 函數，以確保在執行時擁有相容的 numpy 版本

host:
  - numpy

在撰寫本文時（2025 年 1 月），以上內容等同於以下內容，

host:
  - numpy   1.22   # [py==39]
  - numpy   1.22   # [py==310]
  - numpy   1.23   # [py==311]
  - numpy   1.26   # [py==312]

儘管 numpy 2.0 的持續遷移已經應用於許多 feedstock，在這種情況下，pinning 看起來像這樣

host:
  - numpy   2.0    # [py==39]
  - numpy   2.0    # [py==310]
  - numpy   2.0    # [py==311]
  - numpy   2.0    # [py==312]

請參閱 pinning 儲存庫以了解撰寫本文時 pinning 對應的內容 https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml#L742

在任何情況下，實際的執行時需求都透過 numpy 的 run-export 確定，即

  • >=1.2x,<2 如果您針對 numpy 1.2x 建置
  • >=1.19,<3 如果您針對 numpy 2.0 建置
  • >=1.21,<3 如果您針對 numpy 2.1 或 2.2 建置

如果您正在建置的套件對 numpy 有更高的最低需求，請將其新增至 run 下

host:
  # leave this unpinned!
  - numpy
run:
  - numpy >={{ the_lower_bound_your_package_needs }}

JupyterLab 擴充功能​

典型的 JupyterLab 擴充功能同時具有 Python 和 JavaScript 組件。這些組件應打包在一起，以防止 node 需要在使用者機器上抓取套件的 JavaScript 部分。為了打包擴充功能，建置應具有以下 meta.yaml 片段

build:
  noarch: python


requirements:
  host:
    - python {{ python_min }}.*
    - nodejs
    - pip
  run:
    - python >={{ python_min }}
    - nodejs
    - jupyterlab >=2

請在您的 recipe 中使用以下 build.sh 腳本

#!/usr/bin/env bash
set -ex

$PYTHON -m pip install . -vv
npm pack ${PKG_NAME}@${PKG_VERSION}
mkdir -p ${PREFIX}/share/jupyter/lab/extensions/js
cp ${PKG_NAME}-${PKG_VERSION}.tgz ${PREFIX}/share/jupyter/lab/extensions/js

由於這是 noarch recipe，因此建置腳本只需要在 linux-64 上執行。另請注意，我們不需要執行 jupyter labextension install 或 jupyter lab build 作為套件建置的一部分或在任何 post-link 腳本中。這是因為 JupyterLab 將在下次執行時自行執行建置步驟。${PREFIX}/share/jupyter/lab/extensions/js 目錄是 JupyterLab 知道在執行此建置步驟時從中建置的目錄。

訊息傳遞介面 (MPI)​

注意

本節源自 Min 的筆記：https://hackmd.io/ry4uI0thTs2q_b4mAQd_qg

conda-forge 中的 MPI 變體​

如何在 conda-forge 中以最佳方式處理 MPI 變體？

有幾種廣泛的情況

  • 套件需要特定的 MPI 提供者（簡單！）
  • 套件可與任何 MPI 提供者（例如 mpich、openmpi）搭配使用
  • 套件可搭配/不搭配 MPI 使用

請注意，有時使用者希望使用 conda-forge 中針對我們的 MPI 函式庫建置的套件，但在執行時連結到外部 MPI 函式庫。如果您對此程序感興趣，請參閱使用外部訊息傳遞介面 (MPI) 函式庫以取得詳細資訊。

建置 MPI 變體​

在 conda_build_config.yaml 中

mpi:
  - mpich
  - openmpi

在 meta.yaml 中

requirements:
  host:
    - {{ mpi }}

並使用以下命令重新渲染

conda-smithy rerender -c auto

以產生建置矩陣。

包含 no-mpi 建置​

某些套件（例如 hdf5）可能需要 no-mpi 建置，以及 mpi 建置。若要執行此操作，請將 nompi 新增至 mpi 矩陣

mpi:
  - nompi
  - mpich
  - openmpi

並在您的建置中套用適當的條件

requirements:
  host:
    - {{ mpi }}  # [mpi != 'nompi']
  run:
    - {{ mpi }}  # [mpi != 'nompi']

偏好提供者（通常為 nompi）​

到目前為止，mpi 提供者沒有明確的偏好設定。在選擇 MPI 提供者時，mpi 元套件的互斥性允許透過安裝 mpi 提供者來在 mpi 提供者之間進行選擇，例如

conda install mpich ptscotch

或

conda install openmpi ptscotch

這不會擴展到 nompi，因為 mpi 元套件沒有 nompi 變體。而且可能不應該有，因為某些使用 mpi 建置的套件不會排除環境中 *可能* 具有 mpi 變體的其他套件使用函式庫的 no-mpi 變體（例如，長期以來，fenics 使用 mpi 和 no-mpi hdf5，因為當時還沒有並行 hdf5。這可以正常運作，儘管某些功能可能無法使用）。

通常，如果存在偏好設定，則會偏好序列建置，以便套件的安裝程式/請求者僅在明確請求時才取得 mpi 建置。在這種情況下，我們為 nompi 變體使用更高的建置編號。

以下是一個建置章節範例

{% if mpi == 'nompi' %}
# prioritize nompi variant via build number
{% set build = build + 100 %}
{% endif %}
build:
  number: {{ build }}

  # add build string so packages can depend on
  # mpi or nompi variants explicitly:
  # `pkg * mpi_mpich_*` for mpich
  # `pkg * mpi_*` for any mpi
  # `pkg * nompi_*` for no mpi

  {% if mpi != 'nompi' %}
  {% set mpi_prefix = "mpi_" + mpi %}
  {% else %}
  {% set mpi_prefix = "nompi" %}
  {% endif %}
  string: "{{ mpi_prefix }}_h{{ PKG_HASH }}_{{ build }}"
注意

{{ PKG_HASH }} 避免了 *大多數* 變體的建置字串衝突，但對於預設建置字串中排除的套件（例如 Python 本身）則不然。如果套件是針對多個 Python 版本建置的，請使用

string: "{{ mpi_prefix }}_py{{ py }}h{{ PKG_HASH }}_{{ build }}"

如 mpi4py 中所示

此建置章節建立以下套件

  • pkg-x.y.z-mpi_mpich_h12345_0
  • pkg-x.y.z-mpi_openmpi_h23456_0
  • pkg-x.y.z-nompi_h34567_100

這會產生以下後果

  • nompi 變體是首選，除非明確請求 mpi 變體，否則將預設安裝 nompi 變體。
  • 可以使用 pkg=*=mpi_{{ mpi }}_* 明確請求 mpi 變體
  • 可以使用 pkg=*=mpi_* 請求任何 mpi 變體，忽略提供者
  • 可以使用 pkg=*=nompi_* 明確請求 nompi 變體

如果使用此函式庫建置會在變體上建立執行時依賴項，則可以將建置字串 pinning 新增至 run_exports。

例如，如果針對 nompi 變體建置將適用於任何已安裝的版本，但使用給定的 mpi 提供者建置則需要使用該 mpi 執行

build:
  ...
  {% if mpi != 'nompi' %}
  run_exports:
    - {{ name }} * {{ mpi_prefix }}_*
  {% endif %}

如果所有變體都應根據建置時選擇的變體建立嚴格的執行時依賴項（即，如果 nompi 建置無法針對 mpich 建置執行），請移除 if mpi... 條件。

完整範例​

結合以上所有內容，以下是一個完整的 recipe，具有

  • nompi、mpich、openmpi 變體
  • run-exports 將建置時做出的 mpi 選擇套用於執行時，其中 nompi 建置可以與 mpi 一起執行，但反之則不然。
  • 預設情況下，nompi 變體是首選
  • 僅在 Windows 上建置 nompi

這與 hdf5 中完成的操作相符。

# conda_build_config.yaml
mpi:
  - nompi
  - mpich  # [not win]
  - openmpi  # [not win]
# meta.yaml
{% set name = 'pkg' %}
{% set build = 0 %}

# ensure mpi is defined (needed for conda-smithy recipe-lint)
{% set mpi = mpi or 'nompi' %}

{% if mpi == 'nompi' %}
# prioritize nompi variant via build number
{% set build = build + 100 %}
{% endif %}

build:
  number: {{ build }}

  # add build string so packages can depend on
  # mpi or nompi variants explicitly:
  # `pkg * mpi_mpich_*` for mpich
  # `pkg * mpi_*` for any mpi
  # `pkg * nompi_*` for no mpi

  {% if mpi != 'nompi' %}
  {% set mpi_prefix = "mpi_" + mpi %}
  {% else %}
  {% set mpi_prefix = "nompi" %}
  {% endif %}
  string: "{{ mpi_prefix }}_h{{ PKG_HASH }}_{{ build }}"

  {% if mpi != 'nompi' %}
  run_exports:
    - {{ name }} * {{ mpi_prefix }}_*
  {% endif %}

requirements:
  host:
    - {{ mpi }}  # [mpi != 'nompi']
  run:
    - {{ mpi }}  # [mpi != 'nompi']

然後，依賴此套件的套件可以明確選擇適當的 mpi 建置

# meta.yaml

requirements:
  host:
    - {{ mpi }}  # [mpi != 'nompi']
    - pkg
    - pkg * mpi_{{ mpi }}_*  # [mpi != 'nompi']
  run:
    - {{ mpi }}  # [mpi != 'nompi']
    - pkg * mpi_{{ mpi }}_*  # [mpi != 'nompi']

mpi-metapackage 互斥性允許 mpi_* 與 mpi_{{ mpi }}_* 解析為相同，如果 {{ mpi }} 也是直接依賴項，儘管明確說明可能更好。

僅 mpi 範例​

如果沒有首選的 nompi 變體，則需要 mpi 的 recipe 會簡單得多。這就是所需的全部內容

# conda_build_config.yaml
mpi:
  - mpich
  - openmpi
# meta.yaml
requirements:
  host:
    - {{ mpi }}
  run:
    - {{ mpi }}

MPI 編譯器套件​

請勿在 recipe 的 requirements/build 章節中使用 [openmpi,mpich]-[mpicc,mpicxx,mpifort] 元套件；MPI 編譯器包裝器包含在主要的 openmpi/mpich 套件中。如上所示，只需將 openmpi/mpich 新增至 requirements/host 章節，並在 requirements/build 中正常使用對應編譯器的編譯器指示詞即可。

OpenMP​

您可以在 macOS 上透過將 llvm-openmp 套件新增至 meta.yaml 的 build 章節來啟用 OpenMP。對於 Linux，預設情況下 OpenMP 支援處於開啟狀態，但最好明確依賴 libgomp 套件，這是來自 GNU 專案的 OpenMP 實作。

# meta.yaml
requirements:
  build:
    - llvm-openmp  # [osx]
    - libgomp      # [linux]

切換 OpenMP 實作​

在 macOS 上，僅支援 LLVM 的 OpenMP 實作 llvm-openmp。即使在使用 GNU 的 gfortran 編譯的 Fortran 程式碼中，也使用此實作。

在 Linux 上（aarch64 除外），套件會連結到 GNU 的 libgomp.so.1，但在安裝時可以透過執行以下操作將 OpenMP 函式庫從 GNU 切換到 LLVM。

conda install _openmp_mutex=*=*_llvm

可以透過執行以下操作將 OpenMP 函式庫切換回 GNU 的 libgomp。

conda install _openmp_mutex=*=*_gnu
注意

OpenMP 函式庫切換是可行的，因為 LLVM 的實作除了 LLVM 符號（最初來自 Intel）外，還具有 GNU 的符號。由 gcc、g++ 或 gfortran 產生的物件檔案將具有 GNU 的符號，因此可以切換底層函式庫。但是，由 clang 或 clang++ 產生的物件檔案將具有 LLVM 的符號，因此無法將底層 OpenMP 函式庫切換到 GNU 的函式庫。

您可能希望切換到 LLVM 的一個原因是，該實作是 fork 安全的。繼續使用 GNU 實作的一個原因是，libgomp 中的 OpenMP 目標卸載符號（如 GOMP_target）在 LLVM 中是空的 stub，因此無法運作。

yum_requirements.txt​

可以透過在 feedstock 的 recipe 目錄中名為 yum_requirements.txt 的檔案中逐行列出套件名稱，使用 yum 將依賴項安裝到建置容器中。

只有在極少數情況下，使用 yum 安裝的依賴項才是可接受的。這些情況包括

  • 在測試階段滿足 CDT 套件的需求
  • 安裝僅在測試中需要的套件

變更 yum_requirements.txt 後，重新渲染以更新設定。

BLAS​

如果套件需要 BLAS、CBLAS、LAPACK、LAPACKE 其中之一，請在 recipe 的 host 中使用以下內容，

requirements:
  host:
    - libblas
    - libcblas
    - liblapack
    - liblapacke
注意

您應僅指定套件需要的函式庫。（即，如果套件不需要 LAPACK，請移除 liblapack 和 liblapacke）

在 recipe 建置時，上述需求將下載 NETLIB 的參考實作，並針對這些實作建置您的 recipe。在執行時，預設情況下將使用以下套件。

- openblas   # [not win]
- mkl        # [win]

如果套件需要特定實作的內部 API 以獲得更多控制，您可以擁有，

requirements:
  host:
    # Keep mkl-devel here for pinning
    - mkl-devel         {{ blas_impl == "mkl" }}
    - {{ blas_impl }}   {{ blas_impl != "mkl" }}
  run:
    - libblas * *{{ blas_impl }}
    - {{ blas_impl }}

這會為您提供適用於不同 blas 實作的矩陣建置。如果您只想支援特定的 blas 實作，

requirements:
  host:
    - openblas
  run:
    - libblas * *openblas
    - openblas
注意

不應再使用 blas_* 功能。

切換 BLAS 實作​

您可以透過執行以下操作來切換 BLAS 實作，

conda install "libblas=*=*mkl"
conda install "libblas=*=*openblas"
conda install "libblas=*=*blis"
conda install "libblas=*=*accelerate"
conda install "libblas=*=*netlib"

這將變更 BLAS 實作，而不會變更依賴 BLAS 的 conda 套件。

也支援以下舊版命令。

conda install "blas=*=mkl"
conda install "blas=*=openblas"
conda install "blas=*=blis"
conda install "blas=*=accelerate"
conda install "blas=*=netlib"
注意

如果您想提交到特定的 blas 實作，您可以透過在您的環境中 pinning blas 實作來防止 conda 切換回。若要提交到 mkl，請將 blas=*=mkl 新增至 <conda-root>/envs/<env-name>/conda-meta/pinned，如 conda-docs 中所述。

運作方式​

在 recipe 建置時，使用 netlib 套件。這表示下游套件將連結到 libblas=*=*netlib 中的 libblas.so.3，並且僅使用參考實作的符號。

libblas 和 libcblas 版本控制基於參考 LAPACK 版本控制，撰寫本文時為 3.8.0。由於 BLAS API 是穩定的，因此下游套件僅會 pinning 到 libblas 和 libcblas 的 3.*。另一方面，liblapack 和 liblapacke pinning 到 3.8.*。

除了上述 netlib 套件外，還有其他變體，例如 libblas=*=*openblas，它具有 openblas 作為依賴項，並且具有從 libblas.so.3 到 libopenblas.so 的符號連結。libblas=3.8.0=*openblas 將 openblas 依賴項 pinning 到已知支援 BLAS 3.8.0 API 的版本。這表示，在安裝時，使用者可以選擇他們喜歡的 BLAS 實作，而無需了解所需的 BLAS 實作版本。

微架構最佳化建置​

conda 虛擬套件包含 __archspec，它向 solver 公開處理器架構。但是，__archspec 不應直接在 recipe 中使用；相反地，使用者應依賴 microarch-level 輔助套件（在 staged-recipes#24306 中貢獻）。

在學習如何使用它之前，請先閱讀這些注意事項

  • 新增微架構變體可能會導致建置矩陣中出現過多項目。請勿過度使用它。
  • 這些最佳化建置應僅在效能提升顯著時使用。
  • 最好是，專案應依賴執行時調度來進行架構特定的最佳化。
  • 如果套件已經太大，請考慮為架構最佳化變體使用較小的輸出。

若要在您的 feedstock 中實作微架構最佳化建置，您最終會得到類似以下的內容

recipe/conda_build_config.yaml
microarch_level:
  - 1
  - 3  # [unix and x86_64]
  - 4  # [unix and x86_64]
recipe/meta.yaml
# ...
{% set build = 0 %}

build:
  number: {{ build }}          # [not (unix and x86_64)]
  number: {{ build + 100 }}    # [unix and x86_64 and microarch_level == 1]
  number: {{ build + 300 }}    # [unix and x86_64 and microarch_level == 3]
  number: {{ build + 400 }}    # [unix and x86_64 and microarch_level == 4]

requirements:
  build:
    - x86_64-microarch-level {{ microarch_level }}  # [unix and x86_64]
    - {{ compiler('c') }}
    # ...
# ...
優先順序化您偏好的微架構

run_exports metadata 僅使用下限進行設定，以允許在 CI 中進行測試。這表示 level=2 套件可以安裝在 level=3 機器中。請務必為偏好的微架構（通常為最高層級）指定更高的建置編號。

就是這樣！microarch-level 套件背後的啟動腳本已經為您注入了必要的編譯器旗標。由於它們也具有 run_exports 項目，因此您的套件將具有必要的執行時需求，以確保安裝最合適的變體。請參閱 此評論 和 microarch-level-feedstock README 以取得更多資訊。

Matplotlib​

conda-forge 上的 matplotlib 分為兩個部分。核心函式庫位於 matplotlib-base 中。實際的 matplotlib 套件是此核心函式庫加上 pyqt。大多數（如果不是全部）在執行時依賴 matplotlib 的套件都應將此依賴項列為 matplotlib-base，除非它們明確需要 pyqt。其想法是，明確安裝 matplotlib 的使用者將獲得具有 pyqt 的完整功能安裝。但是，pyqt 是一個相當大的套件，因此不間接需要它對於效能更好。請注意，如果匯入連結到 libX11 的 matplotlib 部分，您可能需要在您的 recipe 中包含 yum_requirements.txt 檔案，其中包含

xorg-x11-server-Xorg

如果您匯入連結到 libX11 的 matplotlib 部分。

pybind11 ABI 約束​

有時，當使用 pybind11 的不同 python 函式庫透過較低層級的 C++ 介面互動時，兩個函式庫之間的底層 ABI 必須匹配。為了簡化此使用案例，我們有一個 pybind11-abi 元套件，可用於建置的 host 章節中。其版本是全域 pinning 的，並且它本身具有 run export，這表示 host 中具有此套件的建置將對其具有執行時約束。此外，pybind11 對 ABI 元套件具有 run 約束，以協助確保使用一致性。

若要在建置中使用此套件，請將其放入 host 環境中，如下所示

requirements:
  host:
    - pybind11-abi

空的 Python 套件​

對於較新 Python 版本中引入的某些功能，Python 社群會建立 backport，這使得這些功能也可用於較早版本的 Python。這裡的一個範例是 dataclasses，它是在 Python 3.7 中引入的，但也可作為 Python 3.6 的 backport 使用。因此，大多數上游套件僅對特定版本的 Python 強制要求這些 backport，否則會排除它們。

目前，在 conda-forge 中實作此限制的唯一方法是使用 skips，這會限制相應的 conda-forge recipe 成為 noarch。

因此，某些 conda-forge recipe 僅在特定 Python 版本上建立實際套件，否則為空的佔位符。這允許它們在所有 Python 版本下安全地安裝，並使使用 skips 變得不必要。

同樣地，某些套件僅是套件的平台特定依賴項，例如 pywin32，並且具有輔助元套件，可以協助 recipe 保持 noarch。所需實際套件的版本可以使用 run_constrained 控制，即使對於並非在所有平台上都可用的套件也是如此。

目前可用的套件

名稱可用於在以下版本中為空
backports.strenumpython >=3.8,<3.11python >=3.12
dataclassespython >=3.6,<3.7python >=3.7
enum34python =2.7python >=3.4
pywin32-on-windowswindowsunix
typingpython >=3

非版本特定的 Python 套件​

對於某些依賴項，上游維護者會列出需要這些套件的 Python 版本，即使這些套件實際上可以在所有 Python 版本下安裝。

目前，在 conda-forge 中實作此限制的唯一方法是使用 skips，這會限制相應的 conda-forge recipe 成為 noarch。

因此，conda-forge 社群維護一份套件清單，這些套件在所有 Python 版本下都可以安全安裝，即使原始套件僅在某些版本中需要它們。

例如，套件 pyquil 僅 需要 importlib-metadata 用於 python <3.8，但實際上在 python >=3.8 下安裝也是安全的。

目前可用的套件

  • exceptiongroup
  • importlib-metadata

Noarch 建置​

Noarch 套件是不特定於架構的套件，因此只需要建置一次。

在 meta.yaml 的 build 章節中將這些套件宣告為 noarch，可以減少共用的 CI 資源。因此，所有符合 noarch 套件條件的套件都應宣告為 noarch 套件。

Noarch python​

build 章節中的 noarch: python 指令使純 Python 套件只需建置一次。

為了符合 noarch python 套件的條件，必須滿足以下所有準則

  • 沒有編譯的擴充功能
  • 沒有 post-link 或 pre-link 或 pre-unlink 腳本
  • 沒有 OS 特定的建置腳本
  • 沒有 python 版本特定的需求
  • 沒有 skips，python 版本除外。如果 recipe 僅限 py3，請移除 skip 陳述式，並在 host 和 run 章節中新增 python 的版本約束。
  • 未使用 2to3
  • 未使用 setup.py 中的 scripts 引數
  • 如果在 setup.py 或 setup.cfg 中定義了 console_scripts entry_points，它們也會 列出 在 meta.yaml 的 build 章節中
  • 沒有 activate 腳本

所有採用 noarch: python 的 recipe 通常都應使用 python_min 變數，如下例所示

recipe/meta.yaml
name: package
source:
  # ...
build:
  noarch: python
  # ...
requirements:
  host:
    - python {{ python_min }}
    # ...
  run:
    - python >={{ python_min }}
    # ...

test:
  requires:
    - python {{ python_min }}
    # ...

如需此語法的詳細資訊，請參閱 CFEP-25。如果您需要覆寫此語法，您可以在 recipe 頂端新增 Jinja2 set 陳述式（或 v1 recipe 的等效 context 變數），如下所示

recipe/meta.yaml
{% set python_min = "3.10" %}

也可以透過將包含如下所示地圖的 conda_build_config.yaml 檔案新增至您的 recipe 來達到相同的效果

recipe/conda_build_config.yaml
python_min:
- "3.10"

如果您採用此方法，您需要在新增 conda_build_config.yaml 檔案後重新渲染 feedstock。

使用 noarch: python 套件，在其 test.requires 章節中使用 python {{ python_min }} pins 作為 downstream 測試，如果測試所需的 Python 版本與 upstream 套件的 Python 版本衝突，則可能會導致 upstream 套件失敗。有兩種修正方法，取決於哪個更重要。

  1. 將 downstream 測試約束在 upstream 套件中，使其僅在 python_min 上執行。
  2. 從 downstream 套件的測試需求中移除 python_min 需求。

或多或少，當在 python_min 上測試 downstream 套件是最重要的事情時，您偏好第一種解決方案。當使用 downstream 套件測試 upstream 套件的所有 Python 版本是最重要的事情時，您偏好第二種解決方案。

提示

將明確的 python_min 新增至您的 noarch: python recipe 可以有效地確保在 conda-build 時強制執行套件 metadata 中所需的 Python，因為如果套件所需的 Python 版本比 python_min 新，則建置將會失敗。

注意

雖然 noarch: python 不適用於 selectors，但它適用於版本約束。skip: True # [py2k] 可以替換為主機和執行子章節中受約束的 python 版本：例如 python >=3 而不是僅 python。

注意

只有 console_scripts entry points 必須列在 meta.yaml 中。其他 entry points 不會與 noarch 衝突，因此不需要額外處理。

注意

noarch 是關於套件原始碼的陳述，而不是其安裝環境。即使套件的其中一個依賴項在給定平台上不可用，套件仍然被視為 noarch。如果是這種情況，當 conda 嘗試安裝套件時，將顯示有用的錯誤訊息，描述找不到哪個依賴項。如果稍後提供該依賴項，您的套件將可在該平台上安裝，而無需對 feedstock 進行任何變更。

預設情況下，noarch 套件是在 Linux 上建置的，並且所有依賴項都必須在 Linux 上可用。

提示

如果 noarch 套件無法在 Linux 上建置，則可以在 conda-forge.yml 中提供一個或多個 noarch_platforms。一個範例是 pywin32-on-windows，它在 Linux 和 Windows 上建置，具有 build_number 偏移量以建立一對套件，例如 dataclasses。

提示

您可以建置平台特定的 noarch 套件，以包含依賴於目標 OS 的執行時需求。請參閱以下迷你教學課程。

如果現有的 python 套件符合轉換為 noarch 套件的條件，您可以透過開啟新 issue 並包含 @conda-forge-admin, please add noarch: python 來請求所需的變更。

具有 OS 特定依賴項的 Noarch 套件​

可以建置具有執行時需求的 noarch 套件，這些執行時需求取決於目標 OS（Linux、Windows、MacOS），無論架構（amd64、ARM、PowerPC 等）如何。此方法依賴於三個概念

  1. 虛擬套件。以雙底線為前綴，它們由 conda 用於在安裝時將系統屬性表示為 solver 的約束。我們將使用 __linux、__win 或 __osx，它們僅在執行平台分別為 Linux、Windows 或 MacOS 時存在。__unix 同時存在於 Linux 和 MacOS 中。請注意，此功能**僅在 conda 4.10 或更高版本上完全可用**。
  2. conda-forge.yml 的 noarch_platforms 選項。
  3. conda-build 3.25.0 或更高版本，根據使用的虛擬套件變更建置雜湊。

其想法是為每個需要不同依賴項的 OS 產生不同的 noarch 套件。假設您有一個純 Python 套件，完全符合 noarch: python 的條件，但在 Windows 上，它需要 windows-only-dependency。您可能有類似以下的內容

recipe/meta.yaml (原始)
name: package
source:
  # ...
build:
  number: 0
requirements:
  # ...
  run:
    - python
    - numpy
    - windows-only-dependency  # [win]

作為非 noarch，這表示建置矩陣將至少包含 12 個輸出：三個平台，乘以四個 Python 版本。在混合中使用 arm64、aarch64 和 ppc64le 會使情況變得更糟。如果我們將其替換為另一種方法，我們可以將其減少到兩個輸出！

recipe/meta.yaml (已修改)
name: package
source:
  # ...
build:
  number: 0
  noarch: python
requirements:
  host:
    - python {{ python_min }}.*
    # ...
  run:
    - python >={{ python_min }}
    - numpy
    - __unix  # [unix]
    - __win   # [win]
    - windows-only-dependency  # [win]

請勿忘記使用其 selectors 指定平台虛擬套件！否則，solver 將無法正確選擇變體。

預設情況下，conda-forge 僅在 linux_64 CI runner 上建置 noarch 套件，因此只有 # [unix] selectors 將為 true。但是，我們可以使用 conda-forge.yml 中的 noarch_platforms 選項變更此行為

conda-forge.yml
noarch_platforms:
  - linux_64
  - win_64

這將為每個套件提供兩個 runner！完美！所有這些變更都需要重新渲染 feedstock 才能套用。請參閱重新渲染 feedstock。

如果您需要所有三個作業系統上的條件依賴項，這是您的做法

recipe/meta.yaml
name: package
source:
  # ...
build:
  number: 0
  noarch: python
requirements:
  # ...
  run:
    - python >={{ python_min }}
    - numpy
    - __linux  # [linux]
    - __osx    # [osx]
    - __win    # [win]
    - linux-only-dependency    # [linux]
    - osx-only-dependency      # [osx]
    - windows-only-dependency  # [win]
conda-forge.yml
noarch_platforms:
  - linux_64
  - osx_64
  - win_64

同樣地，請記住在新增/修改這些檔案後重新渲染，以便套用變更。

Noarch generic​

待辦事項

新增一些關於大量使用 noarch: generic 的 r 套件的資訊

多輸出 recipe​

conda-build 能夠透過 meta.yaml 中的 outputs 章節從單一 recipe 建立多個套件成品。這在多種情況下很有用，包括

outputs 的常見陷阱​

這是使用 outputs 時常見陷阱的非詳盡清單。

  • 通常，使用與任何輸出名稱都不符的頂層名稱會更簡單。如果頂層名稱與 feedstock 名稱不同，請務必在 meta.yaml 中設定 extra.feedstock-name。請參閱 rich-feedstock。請注意頂層名稱如何為 rich-split，feedstock 名稱為 rich，而主要輸出也是 rich。
  • build.sh 和 bld.bat 腳本僅自動用於頂層套件。請考慮為輸出中的腳本使用其他檔案名稱。請參閱 gdal-feedstock 以取得範例。
  • outputs[].script 欄位只能設定為腳本名稱。如果您偏好傳遞 shell 命令，則必須使用 outputs[].build.script。請分別比較 geopandas-feedstock 和 gym-feedstock。
  • 通常為頂層腳本設定的某些 PIP_* 環境變數不會自動為輸出設定。如果您在輸出中調用 pip，您可能需要傳遞額外的標誌。請參閱 napari-feedstock。此問題已在 conda/conda-build#3993 中追蹤。

建置矩陣​

目前，python、vc、r-base 將為每個支援的版本建立一個工作矩陣。如果 python 僅是建置相依性，而不是執行階段相依性（例如：套件的建置腳本以 Python 撰寫，但套件不依賴 Python），請使用 build 區段

以下表示 python 僅是建置相依性，並且不會建立 Python 矩陣。

build:
  - python
host:
  - some_other_package

請注意，host 應為非空值，或使用 compiler Jinja 語法，或將 build/merge_build_host 設定為 True，build 區段才會被視為與 host 不同。

以下表示 python 是執行階段相依性，並且將為每個支援的 Python 版本建立一個 Python 矩陣。

host:
  - python

conda-forge.yml 的建置矩陣已在 conda-smithy=3 中移除。若要取得建置矩陣，請在 recipe 資料夾內建立一個 conda_build_config.yaml 檔案。例如，以下設定將為您提供 2 個建置，並且您可以在 meta.yaml 中使用選擇器 vtk_with_osmesa

vtk_with_osmesa:
  - False
  - True

在此變更之後，您需要重新渲染 feedstock。

需要較新的 macOS SDK​

conda-forge 使用 macOS SDK 10.13 來建置軟體，以便它們可以部署到所有 10.13 之後的 macOS 版本。有時，某些套件需要較新的 SDK 才能建置。雖然可以使用以下對 recipe 的變更來覆寫預設版本 10.13，但應將其作為最後手段。如果您認為您需要這樣做，請諮詢核心團隊。

若要使用新的 SDK，請在 recipe/conda_build_config.yaml 中新增以下內容

# Please consult conda-forge/core before doing this
MACOSX_SDK_VERSION:        # [osx and x86_64]
  - "10.15"                # [osx and x86_64]

請注意，如果您收到的錯誤訊息指出找不到標頭檔或未定義巨集，則應執行此操作。這將使您的套件使用較新的 SDK 編譯，但部署目標為 10.13。警告：如果您由於有缺陷的符號可用性檢查而執行上述操作，則某些套件可能會使用 10.15 的功能。例如，尋找 clock_gettime 的套件會將其視為弱符號，但該套件可能沒有處理弱符號的路徑，在這種情況下，您需要更新 c_stdlib_version（先前為 MACOSX_DEPLOYMENT_TARGET），如下所述。

在增加 SDK 版本後，如果您收到錯誤訊息指出某個函式僅適用於 macOS x.x，則請在 recipe/conda_build_config.yaml 中執行以下操作，

# Please consult conda-forge/core before doing this
c_stdlib_version:          # [osx and x86_64]
  - "10.15"                # [osx and x86_64]
MACOSX_SDK_VERSION:        # [osx and x86_64]
  - "10.15"                # [osx and x86_64]

在 recipe/meta.yaml 中，新增以下內容以確保使用者的系統相容。

requirements:
  build:
    - {{ stdlib("c") }}

請注意，stdlib meta-packages 產生的 __osx 上的 run-export 需要 conda>=4.8。

使用舊版 SDK 的較新 C++ 功能​

libc++ 函式庫使用 Clang 可用性註釋，在以隨附系統 libc++ 的 macOS 版本為目標時，將某些符號標記為不可用。Clang 始終假定使用系統 libc++。

conda-forge 建置基礎架構以 macOS 10.13 為目標，並且某些較新的 C++ 功能（例如 fs::path）在該平台上被標記為不可用，因此建置中止

...
error: 'path' is unavailable: introduced in macOS 10.15
...
note: 'path' has been explicitly marked unavailable here
class _LIBCPP_TYPE_VIS path {

但是，由於 conda-forge 運送其自己的（現代）libcxx，因此我們可以忽略這些檢查，因為這些符號實際上是可用的。若要執行此操作，請將 _LIBCPP_DISABLE_AVAILABILITY 新增至 defines。例如

CXXFLAGS="${CXXFLAGS} -D_LIBCPP_DISABLE_AVAILABILITY"

PyPy 建置​

請參閱使用者文件中的 使用 PyPy 作為直譯器，以取得有關 PyPy 和 conda-forge 的更多資訊。

若要為 pypy 建置您的 python 套件，請等待機器人發送 PR，如果在建置相依性之後未發送 PR，請聯絡 conda-forge/bot 團隊。

若要僅為 pypy 或 cpython 新增相依性，請執行以下操作：

requirements:
  run:
    - spam           # [python_impl == 'cpython']
    - ham            # [python_impl == 'pypy']
注意

您需要在進行上述變更後重新渲染 feedstock，以便 python_impl 變數可供 conda-build 使用

若要跳過 pypy 建置，請執行以下操作：

build:
  skip: True         # [python_impl == 'pypy']

如果某些項目在 PyPy 建置中失敗，但在 CPython 建置中通過，請聯絡 @conda-forge/help-pypy。

使用 setuptools_scm​

Python 模組 setuptools_scm 可用於從中繼資料（例如 git 標籤）自動管理套件的版本。因此，套件的版本字串未在套件中的任何位置指定，而是在安裝時編碼在其中。

對於 conda-build，這表示 setuptools_scm 必須包含為 host 相依性。此外，還需要注意，因為中繼資料通常在來源中不可用。有兩種處理方法

  • 對於 PyPI 上也提供的 Python 套件：使用 PyPi tarball 作為來源，因為它將具有編碼的中繼資料（以 setuptools_scm 知道如何找到它的方式）。

  • 使用版本字串指定環境變數 SETUPTOOLS_SCM_PRETEND_VERSION。如果指定了此環境變數，則它是 setuptools_scm 的主要來源。有兩種方法可以執行此操作

    • 如果您使用建置腳本，請在 build.sh 中指定

      export SETUPTOOLS_SCM_PRETEND_VERSION="$PKG_VERSION"

      在 bld.bat 中指定

      set SETUPTOOLS_SCM_PRETEND_VERSION=%PKG_VERSION%

      您可以使用已使用版本字串設定的 PKG_VERSION，請參閱 環境變數。

    • 否則，如果您直接從 meta.yaml 建置，請使用例如

      build:
        # [...]
        script_env:
          - SETUPTOOLS_SCM_PRETEND_VERSION={{version}}
        script: "{{ PYTHON }} -m pip install . -vv"

需要較新的 glibc 版本​

Conda-forge 旨在為盡可能多的使用者進行建置，這表示我們的目標是 CentOS 7 的 glibc 2.17，這允許套件安裝在基本上任何 Linux 系統上（2014 年之後）。

但是，某些 feedstock 可能已經需要較新的 glibc 版本。若要在 linux 上使用具有 glibc 2.28 或 2.34 的較新 sysroot，請在您的建置區段中放置以下內容。

requirements:
  build:
    - {{ compiler('c') }}
    - {{ stdlib('c') }}

並將以下內容新增至 recipe/conda_build_config.yaml

c_stdlib_version:          # [linux]
  - "2.28"                 # [linux]

這涵蓋了建置時存在的標頭檔/函式庫，並且還將在 __glibc 虛擬套件上建立對應的 run-export。

依預設，conda-forge 建置基礎架構在新映像檔上使用舊版 sysroot，這表示 Docker 映像檔中存在的 glibc 不是我們編譯所針對的對象。這有幾個優點，也表示通常您不必擔心手動變更映像檔。

但是，如果由於某些原因您想要覆寫映像檔版本，則可以透過在 recipe 的 conda-forge.yml 中設定以下內容並重新渲染來執行此操作。

os_version:             # example of possible values
  linux_64: cos7
  linux_aarch64: alma8
  linux_ppc64le: alma9

在 feedstock 執行二進制重新封裝（即，不從來源編譯）的特殊情況下，請確保您使用最舊的可能映像檔，使其與 recipe 的 c_stdlib_version 相符。例如，如果您使用預設的 c_stdlib_version 2.17，則設定 os_version: linux_*: cos7；如果您使用 c_stdlib_version 2.28，則將其設定為 alma8。

CUDA 建置​

雖然提供的 CI 機器沒有 GPU，但 conda-forge 確實提供了建置啟用 CUDA 的套件的機制。請參閱 使用 CUDA 的 recipe 維護者指南，以取得更多資訊。如果 feedstock 需要存取額外資源（例如 GPU），請參閱以下章節。

常見問題和已知問題​

在 Windows 上找不到 nvcuda.dll​

用於在 Windows 上安裝 CUDA 工具組的 腳本 無法提供 nvcuda.dll 作為安裝的一部分，因為 CI 機器中實際上沒有 GPU。因此，您可能會在 conda build 的後處理步驟中收到連結錯誤

WARNING (arrow-cpp,Library/bin/arrow_cuda.dll): $RPATH/nvcuda.dll not found in packages,
sysroot(s) nor the missing_dso_whitelist.

.. is this binary repackaging?

目前，您必須將 nvcuda.dll 新增至 missing_dso_whitelist

build:
  ...
  missing_dso_whitelist:
    - "*/nvcuda.dll"   # [win]

我的 feedstock 不再建置舊版 CUDA​

由於新的 CUDA 版本定期發布，conda-forge 需要定期決定在資源限制內將支援多少個版本。截至 2025 年 1 月，conda-forge 支援 CUDA 11 和 12。

若要更新到最新的支援版本，請重新渲染 feedstock。根據上次更新的時間，feedstock 可能還需要其他修復。

需要 GPU 或長時間運行的建置的套件​

conda-forge 可以存取 OpenStack 伺服器，該伺服器提供 GPU 建置和長時間運行的建置（超出通常的 6 小時限制）。如果您的套件需要 GPU 才能建置或測試，或者其編譯時間太長，以至於目前在 CI 之外手動完成，您可以請求存取這些 runners。若要執行此操作

  1. 在 conda-forge/admin-requests 中開啟 PR。請依照儲存庫 README 中的指示操作。請注意，您需要請求您想要存取的資源類型（例如 GPU runners 或長時間運行的 CPU 建置）。合併後，這將為您的 feedstock 啟用自架設的 Github Actions runners。
  2. 為了觸發這些 runners 的工作，維護者必須已閱讀並同意 open-gpu-server 使用條款。您需要在 open-gpu-server 儲存庫中開啟 PR，如其 README 中所述。每個維護者只需執行此操作一次（例如，如果您維護多個 feedstock）。
  3. 最後，您可以設定您的 feedstock 以使用自架設的 runners。在步驟 (1) 中的 PR 合併後，admin-requests 將建立一個 PR。但是，由於 Github 強加的安全措施，當它們修改 Github Actions 工作流程時，無法自動重新渲染。您需要透過在您的機器中執行 conda-smithy rerender 並提交和推送結果來手動重新渲染它。
注意

由於某些技術和法律限制，某些常用的自動化基礎架構不適用於這些 runners。如上所述，conda-forge 機器人將無法再自動重新渲染您的 feedstock。自動合併也將無法正常運作。另請注意，conda-forge 機器人將無法觸發自架設的 runners。關閉並重新開啟 PR 將不起作用，但具有足夠權限的維護者可以透過推送空的 commit 來手動觸發它。

Apple Silicon 建置​

新的 Apple M1 處理器是 conda-forge osx-arm64 建置支援的第一個 Apple Silicon。為了使新的建置透過交叉編譯可用，套件及其相依性需要遷移。這些建置是實驗性的，因為其中許多未經測試。

若要請求特定套件及其所有相依性的遷移

  1. 您的套件可能已在遷移過程中。請檢查 arm osx addition 遷移的狀態。如果您的套件已在遷移過程中，它將顯示在適當的標題下（已完成、PR 中、等待父項等）。
  2. 檢查相關的 feedstock，看看是否已經存在問題或 pull request。在這裡開啟問題是可以的，因為它可能需要幾次以下的迭代，尤其是在需要建置許多相依性的情況下。
  3. 如果沒有任何進展，請查看目前的 conda-forge-pinning。
  4. 如果套件未在其中列出，請建立 PR，將套件名稱新增到 osx_arm64.txt 中的隨機位置。遷移機器人應開始為 repo 及其相依性建立自動 pull request。
  5. 在幾個小時內，狀態頁面應反映相關套件的進度，並幫助您追蹤進度。如果可以，請伸出援手！
  6. feedstock 維護者（可能沒有 M1）將努力進行通過持續整合所需的任何變更。如果您對特定套件有深入的了解，請發表意見，但最重要的是保持耐心和禮貌。
  7. 一旦新的建置可從 anaconda.org 取得，請協助維護者測試套件，並回報任何問題…以及成功案例！

預先發布版本​

Recipe 維護者可以透過將預先發布版本新增至 dev 或 rc 標籤，使其在 conda-forge 上可用。

這些標籤的語意通常應遵循 Python 本身遵循的 準則。

  • rc：Beta 和 Release Candidate (RC)。沒有新功能。僅限錯誤修正。
  • dev：Pre-Alpha 和 Alpha。這些仍然是可能在開發版本和最終版本之間看到重大變更的套件。
注意

未使用 alpha 和 beta 標籤。鑑於迄今為止在 conda-forge 頻道上標籤的輕度使用，引入許多標籤似乎相當不必要。dev 和 rc 似乎是不錯的折衷方案。

注意

某些套件（例如 black）遵循發布週期，其中它們從未發布過非 Beta/Alpha 版本。在這些情況下，這些套件的 conda 套件不需要發布到預先發布標籤。

建立預先發布版本​

若要建立 dev 或 rc 套件，可以向 feedstock 的 dev 或 rc 分支發出 PR。此分支必須變更 recipe/conda_build_config.yaml 檔案，以指向 <package_name>_dev 或 <package_name>_rc 標籤。

例如，matplotlib rc 版本將包含

channel_targets:
  - conda-forge matplotlib_rc

如果 B 的預先發布版本依賴於 A 的預先發布版本，則 A 應具有，

channel_targets:
  - conda-forge A_rc

而 B 應具有，

channel_sources:
  - conda-forge/label/A_rc,conda-forge
channel_targets:
  - conda-forge B_rc

在它們各自 feedstock 的 recipe/conda_build_config.yaml 中。

注意

需要重新渲染才能使這些變更反映在 CI 檔案中。channel_targets 條目對應

安裝預先發布版本​

使用 conda CLI​

使用以下命令，但將 PACKAGE_NAME 替換為您要安裝的套件，並將 LABEL 替換為 rc 或 dev

conda install -c conda-forge/label/PACKAGE_NAME_LABEL -c conda-forge PACKAGE_NAME

例如，讓我們從 rc 標籤安裝 matplotlib

conda install -c conda-forge/label/matplotlib_rc -c conda-forge matplotlib

使用 environment.yml​

使用 MatchSpec 來指定您的套件

dependencies:
  - conda-forge/label/matplotlib_rc::matplotlib=3.7.0rc1

或者，您可以使用 channels 區段來啟用 matplotlib_rc 頻道

channels:
  - conda-forge/label/matplotlib_rc
dependencies:
  - matplotlib=3.7.0.rc1

預先發布版本排序​

如果您希望為您的 dev 或 rc 建置新增數字，您應該遵循 Continuum 針對 conda 中的版本排序提出的 準則。另請參閱 conda 4.2.13 的原始碼。重點是 conda 的排序方式如下

< 1.0
< 1.1dev1    # special case 'dev'
< 1.1.0dev1  # special case 'dev'
== 1.1.dev1   # 0 is inserted before string
< 1.1.0rc1
< 1.1.0

因此，請確保您以某種方式標記您的套件，使 conda-build 輸出的套件名稱將以 rc 標籤上傳的套件排序高於以 dev 標籤上傳的套件。

如何更新您的 feedstock token？​

若要重設您的 feedstock token 並修復上傳問題，請依照以下步驟操作

  1. 前往 conda-forge/admin-requests 儲存庫，並將 examples/example-token-reset.yml 複製到 requests/ 資料夾。
  2. 在 YML 檔案中新增您的 feedstock 名稱。新增名稱時，請勿在末尾新增 "-feedstock"。例如：對於 python-feedstock，只需新增 python 即可。

使用 arch_rebuild.txt​

如果 feedstock 需要使用不同的架構/平台（例如 ppc64le 或 aarch64）重新建置，您可以將其新增至 arch_rebuild.txt。檢查 遷移狀態，以查看您的套件是否已在佇列中等待遷移。如果沒有，您可以透過開啟 PR 到 conda-forge-pinning-feedstock 儲存庫，將 feedstock 新增至 arch_rebuild.txt。PR 合併後，遷移機器人會掃描 arch_rebuild.txt 中的 feedstock 清單，並為任何新的 feedstock 及其相依性開啟遷移 PR，從而啟用 aarch64/ppc64le 建置。

遷移器和遷移​

當對套件的全域釘選進行任何變更時，則需要在其 host 區段中需要該套件的整個套件堆疊進行更新和重新建置。手動執行可能非常繁瑣，這就是遷移可以提供幫助的地方。遷移自動化了向 feedstock 提交變更的過程，並且是 regro-cf-autotick-bot 職責不可或缺的一部分。

有幾種類型的遷移，您可以在 製作遷移器 中閱讀有關遷移的資訊。若要產生這些遷移，您可以使用遷移器，遷移器是自動為 conda-forge 中受影響的套件建立 pull request 的機器人。若要在一個或多個釘選中提出遷移，遷移器會使用 yaml 檔案向 pinning feedstock 發出 PR，該檔案表示遷移資料夾中全域釘選檔案的變更。PR 合併後，會建置相依性圖。之後，機器人會遍歷圖表，逐一遷移所有節點 (feedstock)，並為這些 feedstock 發出 PR。

通常，機器人會自動產生這些遷移。但是，當首次建立或新增釘選時，可能需要手動新增一個。若要執行此操作，您可以依照 更新套件釘選 中提到的步驟操作。

遷移的進行方式如下

  1. 您在 conda-forge-pinning-feedstock 中的 migrations 資料夾中建立 PR，其中包含代表遷移的新 yaml 檔案。
  2. PR 合併後，機器人會接收它，建置遷移器圖表，並開始遷移過程。
  3. 僅當滿足以下條件時，才會為節點（feedstock）發出遷移 PR
- The node depends on the changed pinnings.
- The node has no dependencies that depend on the new pinnings and have not been migrated.
  1. 流程 3 繼續進行，直到遷移完成，並且透過最終 PR 將變更應用於全域釘選檔案。在此步驟之後，我們說此遷移已結束。

有時，您可能會收到您不想合併的套件的遷移 PR。在這種情況下，您應該將該 PR 設為草稿狀態，但絕不應關閉它。如果您關閉 PR，它會使機器人認為另一個實作遷移的 PR 已合併，從而讓遷移繼續在圖表上迭代；但是，下游相依項失敗，因為父項（我們關閉 PR 的那個）實際上並未重新建置。保持 PR 開啟或處於草稿狀態的另一個好處是，如果人們將來想要提供幫助，他們可能會提供幫助。

在某些情況下，可能不會開啟遷移 PR。請在我們的狀態頁面上尋找遷移，以查看是否存在任何問題。這可能會顯示仍有相依性需要遷移，在這種情況下，最好的方法是等待（或在可能的情況下提供幫助遷移這些相依性）。如果出現機器人錯誤，將會有指向 CI 工作的連結，以提供有關可能出錯的更多詳細資訊。在這些情況下，請提出問題並包含盡可能多的資訊。

值得注意的是，人們也可以選擇自行建立遷移 PR。如果機器人發生錯誤並且仍在調查中，或者遷移 PR 被意外關閉，這可能是一個不錯的選擇。若要手動遷移 PR

  1. Fork feedstock 並在本地複製它
  2. 建立新分支
  3. 在 feedstock 中建立目錄 .ci_support/migrations（如果不存在）
  4. 將遷移器從 conda-forge-pinning 的遷移器 複製到 .ci_support/migrations 並提交它
  5. 重新渲染 feedstock
  6. 推送這些變更並開啟 PR

conda-forge 建置的安全性考量​

所有 conda-forge 套件都是由網際網路上的陌生人在公共雲端基礎架構上從您可能未檢查過的原始碼建置的，因此如果您或您的團隊需要高安全級別，則不應使用 conda-forge 套件。如果您至少希望有那麼多的監督，您也可以自由下載 recipe 並自行重新建置它們。但是，許多人一直使用 conda-forge，沒有任何問題，以下是 conda-forge 在某些方面幫助提高安全性的一些措施

  1. 來源（您在其中指定套件原始碼的來源位置）可以從 GitHub、PyPI 或其他來源提取，並且始終使用 sha256 雜湊，因此標籤的移動或新 sdists 的上傳不會導致自動套件重新建置。此外，一旦套件被接受並製成 feedstock，只有該 feedstock 的維護者才有權合併對該 feedstock 提出的 PR。
  2. 每個 feedstock 只能上傳該 feedstock 的套件。這是透過使用 cf-staging 頻道來強制執行的，建置首先會發送到該頻道。然後，機器人會評估提交的 feedstock 是否有權限建置其提交的套件，然後才會將建置轉發到 conda-forge 頻道。這有助於減輕不良行為者獲得對不顯眼 feedstock 的存取權，然後嘗試將包含惡意程式碼的建置推送到重要的基礎架構套件（例如，OpenSSL 或 Python）的風險。
  3. 我們有 artifact-validation，用於驗證所有上傳到 anaconda.org 的 conda-forge artifacts。此驗證掃描各種與安全性相關的項目，例如覆寫某些套件關鍵部分的 artifacts。
  4. 我們有一個專門的 安全性與系統子團隊，他們努力確保安全並維護對 conda-forge 使用的憑證和服務/系統的適當存取權。

如果您發現 conda-forge 存在與安全性相關的問題，請查看我們的 安全性政策，以了解如何負責任地報告它。

上游專案的重大變更​

我們不時會對上游專案進行變更，以便它們更好地整合到 conda-forge 生態系統中。我們在此處列出了一些（但並非全部）針對特定專案的變更以及任何相關文件。

Python​

我們攜帶了大量的 python patches，這些 patches 變更了圍繞搜尋路徑、conda 環境中的環境隔離以及某些作業系統限制的一些核心行為。請參閱 python feedstock 以取得更多詳細資訊。