維護套件
重要注意事項
conda-forge 上的套件是不可變的
根據政策,我們不允許編輯或刪除 conda-forge 上的套件。此政策非常重要,因為它可以提高使用 conda-forge
通道建立的 conda
環境的可靠性和可重現性。請注意,由於此政策,我們的上傳腳本將拒絕上傳已存在於 conda-forge
通道上的套件。
如果您需要移除套件,請參閱關於標記套件損壞的章節。
Fork 和拉取請求 (PR)
所有維護者都獲得了他們維護的源料庫的推送權限。這表示維護者可以在主儲存庫中建立分支。對於更新,不鼓勵在主儲存庫中使用分支,因為:
-
持續整合 (CI) 會在分支和拉取請求 (PR) 上執行。
這會浪費持續整合 (CI) 資源
-
分支會自動發布。
這表示如果您將版本更新推送到分支,然後建立拉取請求 (PR),則 conda 套件將在拉取請求 (PR) 合併之前發布到 anaconda.org。
由於這些原因,要求維護者將源料庫 Fork 到他們的個人帳戶,推送到 Fork 中的分支,然後開啟一個拉取請求 (PR) 到 conda-forge 儲存庫。
推送到 regro-cf-autotick-bot 分支
當套件的新版本在 PyPI/CRAN/.. 上發布時,我們有一個機器人會自動為源料庫建立版本更新。在大多數情況下,您只需合併此拉取請求 (PR),它應包含所有變更。當上游的某些內容發生變更時,例如相依性,您仍然必須對建立的拉取請求 (PR) 進行變更。作為源料庫維護者,您不必為此建立新的拉取請求 (PR),而只需推送到機器人建立的分支即可。有兩種替代方法可以推送到機器人的分支
-
手動設定 git 遠端
-
複製 conda-forge 源料庫
-
新增機器人的遠端:
git remote add regro-cf-autotick-bot [email protected]:regro-cf-autotick-bot/<package>-feedstock.git
重要無法使用
git://
協定推送到 GitHub 儲存庫。請參閱 我應該使用哪個遠端 URL? 以取得關於在使用https://
協定(如果您已啟用雙因素身份驗證)的指示。 -
提取遠端:
git fetch regro-cf-autotick-bot
-
簽出拉取請求 (PR) 的分支,如果這是唯一具有該名稱分支的遠端,則 git 應自動將其連結到 regro-cf-autotick-bot 遠端。
-
如果有多個具有此分支名稱的遠端,您需要先簽出遠端分支,然後將其轉換為本機分支:
git checkout regro-cf-autotick-bot/<branch> && git checkout -b <branch>
-
在該分支上提交和推送,如果遠端未正確設定,請使用
git push -u regro-cf-autotick-bot <branch>
。
-
-
使用 Github 的 hub 工具(conda-forge 隨附!
conda install hub -c conda-forge
)- 複製 conda-forge 源料庫
- 使用遠端簽出正確的分支:
hub pr checkout 12
,其中12
是拉取請求 (PR) 的 ID。 - 在此分支上提交和推送,遠端會自動設定為推送到 regro-cf-autotick-bot 的 Fork。
regro-cf-autotick-bot 如何建立自動版本更新?
regro-cf-autotick-bot 在迴圈中持續搜尋任何 PyPI 發行版本、GitHub 發行版本和任何其他版本來源,以了解何時發布任何更新。在迴圈中執行的原始碼來自 cf-scripts 儲存庫,其中包含偵測版本和提交拉取請求 (PR) 的程式碼。請造訪 cf-scripts 以閱讀更多相關資訊。
機器人透過檢查上游發行版本來建立更新,並且始終會更新配方元數據中的 source
區段和建置版本。作為實驗性功能,autotick 機器人也可以設定為驗證或更新與 Grayskull 相容的配方的需求。這可能有助於維護具有頻繁需求變更或特定需求版本釘選的套件,但是此功能尚未經過廣泛驗證,提出的更新應進行審查。(請參閱 conda-forge.yml
中的機器人區段)
有時機器人可能需要數小時才能搜尋這些更新。您也可以查看所有待處理版本更新的版本更新狀態。這些版本更新正在等待中,可能是因為找到了更新的版本,但尚未開啟拉取請求 (PR),或者因為機器人在建立拉取請求 (PR) 時可能發生錯誤。如果您在此處找不到版本,則表示機器人也很可能找不到它。
當套件源料庫有三個或更多開啟的版本更新拉取請求 (PR) 時,機器人會停止建立版本更新拉取請求 (PR)。套件的維護者應關閉或合併這些拉取請求 (PR),以使機器人針對未來的版本更新正常工作。
更新套件的範例工作流程
在此,我們假設您想要更新源料庫 <feedstock>
。源料庫是佔位符,例如可以替換為 numpy-feedstock
。
-
Fork 源料庫
在您可以提交您的第一個拉取請求 (PR) 之前,您必須 Fork conda-forge 的源料庫。
- 導航至 https://github.com/conda-forge/
在您最喜歡的網路瀏覽器中,然後點擊 fork
按鈕。 - 您現在在
https://github.com/<your-github-id>/<feedstock>
中擁有一個您控制的源料庫副本。 - 透過使用
git clone https://github.com/<your-github-id>/<feedstock>
從您的電腦連線到源料庫。
- 導航至 https://github.com/conda-forge/
-
將您的 Fork 與 conda-forge 的源料庫同步
如果您在一段時間前 Fork 了,並且您的 Fork 缺少 conda-forge 源料庫的提交,則僅需要執行此步驟。
- 確保您在主分支上:
git checkout main
- 使用
git remote add upstream https://github.com/conda-forge/<feedstock>
註冊 conda-forge 的源料庫 - 使用
git fetch upstream
提取最新的更新 - 將最新的變更拉入您的主分支:
git rebase upstream/main
- 確保您在主分支上:
-
在新分支中建立您的變更
現在您已準備好更新配方
- 建立並切換到新分支:
git checkout -b <branch-name>
。<branch-name>
可以是例如update_1_0_1
。 - 在本機端進行變更
- 檢閱您的變更,然後使用
git add <changed-files>
。其中<changed-files>
是您變更的檔案名稱的空白分隔清單。 - 透過
git commit -m <commit-msg>
建立提交,其中<commit-msg>
可以是updated feedstock to version 1.0.1
- 建立並切換到新分支:
-
將您的變更推送到 GitHub 並提出拉取請求 (PR)
- 將具有變更的分支推送到您在 GitHub 上的 Fork:
git push origin <branch-name>
- 透過網路介面建立拉取請求 (PR),方法是使用您的網路瀏覽器導航至
https://github.com/<your-github-id>/<feedstock>
並點擊按鈕create pull request
。
- 將具有變更的分支推送到您在 GitHub 上的 Fork:
更新配方
更新配方時,請遵循以下指南
- 更新配方時,始終使用源料庫的 Fork。
- 當套件的版本未變更,但其他元數據或配方的部分已變更時,請將建置編號增加
1
。 - 發布套件的新版本時,請將建置編號重設為
0
。
重新渲染源料庫
重新渲染是 conda-forge 更新所有源料庫共用檔案(例如 README、持續整合 (CI) 設定、釘選相依性)的方式。
重新渲染可以透過兩種方式完成
- 透過新增註解
@conda-forge-admin please rerender
,使用網路服務在雲端執行 conda-smithy(請參閱管理網路服務)。- 在本機機器上本機執行 conda-smithy(請參閱在本機端使用 conda-smithy 重新渲染)。
在本機端使用 conda-smithy 重新渲染
第一步是在您的根環境中安裝 conda-smithy
。
conda install -c conda-forge conda-smithy
提交所有變更,並從源料庫的根目錄中,輸入
conda smithy rerender -c auto
或者,可以手動提交變更。為此,請從命令中刪除 -c auto
。
何時重新渲染
當源料庫的以下部分發生變更時,我們需要重新渲染
- 平台設定(
skip
區段)。 yum_requirements.txt
或conda-forge.yml
。- 由於新版本的 Python、NumPy、PERL、R 等,建置矩陣中的更新。
- 影響源料庫的 conda-forge 釘選中的更新。
- 源料庫設定更新將修復的建置問題(在 Zulip 上關注我們以了解這些問題)。
針對新發布的 Python 版本進行更新
當發布新的 Python 版本(例如 3.11
)時,將觸發自動遷移程序,該程序最終將使 @regro-cf-autotick-bot
自動開啟所有源料庫的拉取請求 (PR),更新其持續整合 (CI) 設定以將新的 Python 版本包含在建置矩陣中。在驗證拉取請求 (PR) 建置通過後,可以簡單地合併該自動拉取請求 (PR) 以為新的 Python 版本推出套件。但是,此過程需要時間,並且不會同時為所有源料庫開啟拉取請求 (PR),以免 CI 負載過重。可以在遷移狀態頁面上追蹤目前的遷移狀態,並且維護者可以在該頁面驗證他們的源料庫是否列在 AWAITING-PR
下拉式清單下。
在本機端測試變更
如果您的系統上安裝了 docker,您可以在與我們的持續整合 (CI) 建置相同的設定下,在本機機器上測試建置。
如果您想在本機端建置和測試源料庫的更新,請前往根源料庫目錄並執行
python build-locally.py
這將提示您在 .ci_support/
中選擇其中一個 *.yaml
設定檔。請注意,需要 shyaml
才能從這些檔案中解析 docker_image
。否則,建置將使用預設的 docker_image
。
或者,您可以提前指定要使用的設定,例如(假設您希望在 Linux 上建置和測試 python 3.6,並且在 .ci_support/linux_python3.6.yaml
中存在這樣的設定檔)
python build-locally.py linux_python3.6
請注意,對於冗長的建置日誌,可以執行
python build-locally.py 2>&1 | tee log.txt
將其儲存到文字檔中以供日後檢查。
建置完成後,您可以在源料庫的 build_artifacts
目錄中找到完成的套件,該目錄可以用作通道。
若要使用 conda 建立新的環境 my-new-env
,並且其中將包含新的建置套件 my-package
,請執行
conda create -n my-new-env -c "file://${PWD}/build_artifacts" my-package
如果新的建置套件依賴另一個要工作的套件,即 other-package
,並且該套件例如在 conda-forge
通道上可用,則您可以執行
conda create -n my-new-env -c "file://${PWD}/build_artifacts" -c conda-forge my-package other-package
從持續整合 (CI) 下載預先建置的套件
源料庫的一個巧妙功能是能夠將套件上傳到 CI 提供者以進行測試。當嘗試測試在拉取請求 (PR) 中建置的套件時,這非常有用。但是您首先需要下載這些預先建置的套件。
若要下載預先建置的套件,請按照以下步驟操作
- 從您的拉取請求 (PR) 開始,導航至 CI。
- 開啟對應於您要下載的套件的日誌。
- 在此日誌中找到
artifacts produced
的連結。 - 從出現的已發布成品清單中,下載您需要的封存檔。
- 取消封存並解壓縮所需的套件。
移除損壞的套件
有時會發生錯誤,並且損壞的套件最終會上傳到 conda-forge
通道。
如果唯一的問題在於套件元數據,我們可以透過使用儲存庫資料修補程式源料庫直接修補它。如果是這種情況,則應遵循以下一般指南
- 更新源料庫配方以確保未來的建置不會使用新的建置編號傳播問題。
- 請在此處建立拉取請求 (PR) 以新增修補程式。修補程式應盡可能詳細地指定套件產生的版本和時間。它可以使用以下資訊
- 目前的時間戳記,您可以使用
python -c "import time; print(f'{time.time():.0f}000')"
產生它。- 要影響的套件的問題版本和建置編號。
如果套件的實際內容損壞,則以下步驟將從 main
通道中移除損壞的套件
- 在 anaconda.org 上找到損壞檔案的路徑,方法是搜尋 conda-forge 套件並切換到檔案標籤。
- Fork conda-forge/admin-requests 並在
requests
目錄中新增一個新的 YML 檔案。 - 將損壞的檔案新增到新的 YML 文件中。請參閱 examples/example-broken.yml 以取得範例檔案。
- 開啟新的拉取請求 (PR)。合併後,機器人會將所有列出的檔案標記為損壞,從而有效地將它們從通道中移除。
封存源料庫
如果套件不再維護,conda-forge 將封存儲存庫。封存的儲存庫不再接受拉取請求 (PR) 和問題,這會阻止人員和 regro-cf-autotick-bot
更新套件(範例是重新渲染源料庫以支援新的 Python 版本)。請注意,這不會移除現有的套件,這些套件仍然可用。
如果您認為應該封存源料庫,請執行以下操作
- 在源料庫上提出問題,詢問是否可以封存它(抄送維護團隊和 @conda-forge/core)
- Fork conda-forge/admin-requests 並在
requests
目錄中新增一個新的yml
檔案,命名為<package>-archive.yml
並包含
action: archive
feedstocks:
- <name of the feedstock to archive without the -feedstock suffix>
範例
action: archive
feedstocks:
- or-datasets
您可以在同一個請求中列出多個源料庫。
- 開啟拉取請求 (PR) 並交叉引用步驟 1 中提出的問題。
更新維護者列表
源料庫的維護者列表記錄在配方本身中。可以透過在源料庫儲存庫中開啟具有以下標題的問題來新增新的維護者
@conda-forge-admin,請新增使用者 @username
其中 username
是要新增的新維護者的使用者名稱。將自動建立拉取請求 (PR),如果沒有維護者再活動,則維護者或 core
團隊的成員可以合併此拉取請求 (PR) 以新增使用者。若要聯絡 core,請透過在註解中提及 @conda-forge/core 來 ping 他們,或者,如果您在一段時間內沒有收到回覆或剛接觸 conda-forge,請透過社群Zulip 聊天室聯絡他們。
此拉取請求 (PR) 旨在跳過建置套件。請勿修改它或調整提交訊息。
這不是開始協助源料庫的建議方式。如果您有興趣協助特定的配方,最好從提交具有新版本或修復程式的拉取請求 (PR) 開始。這樣,您可以獲得對您工作的回饋,並了解源料庫的一些歷史背景。
一旦您與維護者建立了工作關係,您可以要求他們將您新增到源料庫團隊。然後他們可以使用此命令將您新增到團隊。對於如何新增新的維護者沒有任何官方要求,因此可能需要一段時間才能就何時新增新的維護者達成共識。不要讓這阻止您做出貢獻!
任何人都可以自由開啟拉取請求 (PR)!!!感謝您的時間和努力!!!
有關範例,請參閱此問題。
維護多個版本
如果您想維護套件的多個版本,您可以使用源料庫上的分支。若要執行此操作
- Fork 您的源料庫並建立有意義的分支名稱(例如,v1.X 或 v1.0)。
- 對配方進行必要的變更並重新渲染源料庫。
- 然後將此分支從您的 Fork 推送到上游源料庫。我們的持續整合 (CI) 服務將自動建置預設分支以外的任何分支。