conda-forge 核心會議 2023-11-29

在 您的 __new__() 議程項目 標題下新增議程項目

• Zoom 連結
• 我的時區的會議時間
• 上週會議

出席者

姓名	縮寫	GitHub ID	所屬機構
Daniel Ching	DJC	carterbox	Argonne 國家實驗室
Bianca Henderson	BH	beeankha	Anaconda
Marcel Bargull	MB	mbargull	Bioconda/cf
Marcelo Trevisani	MDT	marcelotrevisani	conda-forge
Marius van Niekerk	MvN	mariusvniekerk	Voltron Data / cf
Cheng H. Lee	CHL	chenghlee	Anaconda/cf
John Kirkham	JK	jakirkham	cf/NVIDIA
Matthew R Becker	MRB	beckermr	cf
Dave Clements	DPC	tnabtaf	Anaconda
Wolf Vollprecht	WV	wolfv	prefix.dev

共 13 人

常設項目

• [ ]

來自上次會議的項目

• (JK) Miniforge 23.10
  • https://github.com/conda-forge/miniforge/issues/511
  • 受阻於 conda-build、conda-libmamba-solver 錯誤互動；預計 conda 23.11 將修復這些問題。
  • (JRG) 如果沒有使用者需求/急迫性，我們應該等到 conda 在未來幾天發布。
  • (JK) 延後至下次核心會議
• (JK) NumPy 2.0
  • https://github.com/numpy/numpy/pull/24861#issuecomment-1776781838
  • 預計上游 numpy 2.0 版本將在 2023 年底/2024 年初發布，因此我們應該準備好處理此事。
  • 作為一個群體，我們應該決定我們希望 numpy 做什麼，並將其記錄為新的 numpy issue 或評論網頁 repo issue ( https://github.com/conda-forge/conda-forge.github.io/issues/1997 )。
• (JRG) 新的 conda-forge.org 計劃
  • https://github.com/conda-forge/conda-forge.github.io/issues/1971
  • 舊的紅色/橘色 + 綠色配色方案存在可訪問性問題
  • 確保在遷移到新框架時，我們不會破壞（永久）連結
  • 尋找另一種遠離紅色+黑色的強調色。
    • 大家可能也覺得藍色和綠色也不錯
    • 橘色在一般情況下也存在一些可訪問性問題
    • 一些調色板
      • https://coolors.co/edf0da-f0dfad-8f2d56-ff6542-218380
      • https://coolors.co/1be7ff-6eeb83-e4ff1a-ff6542-e8aa14
  • 狀態頁面：進度條應將「在 PR 中」計為完成
  • 文檔深處的一些交叉連結無法運作。
• (HV) 關於 Alma 8 的 CDT 的處理方式

  • 理想情況下，製作一份 CDT 清單，用於檢查是否可以將每個 CDT 切換到 conda 套件。

  • 在選擇要構建還是重新封裝哪些 CDT 套件時，我們應該考慮/使用哪些約束/標準？

    • 一般來說，避免構建「太接近硬體」的套件
    • 否則，像我們對 X11 套件所做的那樣，從原始碼構建。
    • 需要弄清楚我們想要構建哪些版本（「夠舊」和/或與 Alma 8 ABI 匹配）
    • 對於哪些已構建的套件，我們想要/可以安全地忽略 run_exports？（基本上，不是在運行時拉入的 host-only 套件。）

  • 生成清單不會是一個人就能完成的任務。將需要多位社群成員的意見。

  • 這將會有很多工作，所以我們應該現在開始。

進行中的投票

• [ ]

您的 __new__() 議程項目

• (JK) CUDA Docker 映像檔
  • Nvidia 因為發行版達到 EOL 而移除 CentOS 8 映像檔；唯一的映像檔將是 UBI8、Rocky Linux。
  • 目前 conda-forge 已切換到 UBI8
  • 「僅對」CUDA 11 重要。在幾年內，我們應該已轉換為 CUDA 的 conda 套件，並消除了對 Docker 映像檔的需求。
• (DJC) CUDA 架構目標和修剪 CUDA 架構的政策
  • https://github.com/conda-forge/conda-forge.github.io/issues/1901
  • 某些套件太大，無法在 6 小時 CI 限制內構建，同時針對許多 CUDA 架構
    • 範例包括 libmagma、libtorch
  • 維護者並不總是知道 CUDA 真實/虛擬架構如何運作
  • 某些專案沒有預設目標 CUDA 架構
  • 連結的討論是關於當上游專案沒有預設值時，應該針對哪些 CUDA 架構，以及為了在 6 小時內完成構建，應以什麼順序捨棄架構
  • 我們是否可以為（feedstock）維護者提供關於要針對哪些 CUDA 架構的更好指導？
  • 6 小時以上構建時間的一些解決方案
    • 將 libtorch 構建 Python 擴展與 libtorch 分開（目前上游不支持；需要工作，不明確需要多少工作，需要詢問）
    • 使用即將推出的 GPU 伺服器在那裡運行構建（無時間限制）
    • 讓 archspec 檢測 CUDA 架構將使其中一些討論變得毫無意義，並減輕 6 小時限制
      • 虛擬套件使套件的可移植性降低
  • 目前沒有政策；暫時使用私有伺服器；研究協助 pytorch 分割；查看 cudarchspec 套件

延後至下次會議

• (JK) Miniforge 23.10
• (JK) CUDA 11.8
• (JK) CUDA 12.x
• (JK) Conda + libmamba
• (JK) Alma 映像檔在 Quay 上的公開可見性
• (HV) 封存 k* 生態系統（請參閱此處的最後一條評論 here，來自核心的五個 +1 讚）
  • 已死透，一直是遷移的持續頭痛問題
  • 封存是可逆的，所以我們終於要咬緊牙關做了嗎？
  • 如果有人想恢復，可以在 feedstock README（或釘選的 issue）中留下說明；儘管這種可能性很小...
• (HV) error_overlinking: true 的遷移？
  • 已經為 staged-recipes 中的新 feedstock 設定，也應該推廣到現有的 feedstock（最終）。
  • 這將是一個很好的機會來進行 {{ stdlib }} 相關的更改（例如，移除對 C/C++ stdlib 的隱式 run-export --> 必須在 recipe 中指定，error_overlinking 將找到遺失的實例；如果不是必要的，套件依賴項將通過遷移而精簡 🥳）

CFEPs

• [ ]