conda-forge 核心會議 2024-11-13
在 您的 __new__() 議程項目 標題下新增議程項目
與會者
| 姓名 | 縮寫 | GitHub ID | 隸屬關係 |
|---|---|---|---|
| Marco Esters | ME | marcoesters | Anaconda |
| Daniel J Ching | DJC | carterbox | NVIDIA/conda-forge |
| Klaus Zimmermann | KZ | zklaus | Quansight |
| Cheng H. Lee | CHL | chenghlee | Anaconda/conda-forge |
| Scott Hain | SMH | scotthain | Anaconda |
| Dasha Gurova | DG | dashagurova | Anaconda |
| John Kirkham | JK | jakirkham | NVIDIA/cf |
共 X 人
常設項目
- [ ]
來自先前會議
- [ ]
進行中投票
- [ ]
您的 __new__() 議程項目
- (DJC) conda-forge 預設建置容器應始終具有我們發布的最新 glibc/sysroot 套件
- https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/6283#issuecomment-2453101928
- 預設為最新的 os 使 os_version 與大多數使用者無關，因為 glibc 向後相容性
- glibc 限制仍然由建置時的 sysroot 套件設定；此套件可能會落後於容器中的 sysroot
- (HV) 為了清楚起見，我會將重點 формулировать 為：「conda-forge 應預設使用最新的可用映像檔版本 (與我們發布的最大 sysroot 同步)」
- (HV) 完全支持此提案；草稿實作 此處
- (HV) 也建議從 CUDA zip 中移除
c_stdlib_version-- 根據「始終使用最新映像檔」的政策，這不再必要 (實際上對常見用例 有害) - 其他說明
- HV：系統映像檔與建置過程幾乎無關，僅與支援
__glibc虛擬套件的執行時限制相關。 - IF：同意繼續進行，但應注意確保 cuda-* 重新封裝的東西仍然適用於原始 GLIBC / Docker 映像檔。在這些情況下覆寫，因為這些重新封裝的建置不使用我們的 sysroot，而且我們無法以其他方式確保它們適用於可用的最低 Docker 映像檔。
- HV：後果是在執行二進制重新封裝的 feedstock 的
conda-forge.yml中使用os_version: linux_*: alma8
- HV：系統映像檔與建置過程幾乎無關，僅與支援
- 摘要：可以進行，但二進制重新封裝 feedstock 應按照上述方式釘選 os_version (以保持他們聲稱支援的任何最低版本) 在 提升預設映像檔之前。
- (HV) 提議整合映像檔名稱：https://github.com/conda-forge/docker-images/issues/293
- IF/CHL：Jinja 變數無法在
conda_build_config.yaml中使用 - 在標籤中使用發行版名稱 (也適用於 CUDA 11.8)；儘管缺乏針對它的模板
- (關於捨棄 CUDA 11.8 以免需要對應 Docker 映像檔的一些對話。這最終會發生，但還不是現在。)
- IF/CHL：Jinja 變數無法在
- (JRG)
conda-forge/miniforge被 Google 視為「危險網站」。- 請參閱 https://github.com/conda-forge/miniforge/issues/667
- 建議的解決方案：將內容移至 conda-forge.org，我們擁有審查和爭議的所有權。
- 想法？
- 共識：試試看。
- (HV) 如何處理 CUDA 12.x？
延至下次會議
- (ME) 用於建置安裝程式 (Miniconda、Miniforge 等) 的複合動作
- [ ]
CFEPs
- [ ]