conda-forge 核心会议 2023-11-29

在 Your __new__() agenda items 标题下添加新的议程项

• Zoom 链接
• 我的时区会议是什么时间
• 上周的会议

与会者

姓名	首字母	GitHub ID	隶属关系
Daniel Ching	DJC	carterbox	阿贡国家实验室
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 问题或评论网页仓库问题（ 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 软件包与重新打包哪些 CDT 软件包时，我们应该考虑/使用哪些约束/标准？

    • 通常，避免构建“过于接近硬件”的软件包
    • 否则，像我们对 X11 软件包所做的那样从源代码构建。
    • 需要弄清楚我们要构建哪些版本（“足够旧”和/或与 Alma 8 ABI 匹配）
    • 对于哪些构建的软件包，我们可以/可以安全地忽略 run_exports？（本质上，运行时未拉入的 host-only 软件包。）

  • 生成列表不会是一项单人任务。将需要多个社区成员的投入。

  • 这将是一项大量的工作，因此我们应该立即开始。

正在进行的投票

• [ ]

您的 __new__() 议程项

• (JK) CUDA Docker 镜像
  • Nvidia 正在移除 CentOS 8 镜像，因为发行版已达到 EOL；唯一保留的镜像将是 UBI8、Rocky Linux。
  • 当前已将 conda-forge 切换到 UBI8
  • “仅对” CUDA 11 重要。几年后，我们应该已过渡到 CUDA 的 conda 软件包，并消除了对 Docker 镜像的需求。
• (DJC) CUDA arch 目标和修剪 CUDA arch 的策略
  • https://github.com/conda-forge/conda-forge.github.io/issues/1901
  • 某些软件包在针对许多 CUDA 架构时，体积过大，无法在 6 小时的 CI 限制内构建
    • 示例包括 libmagma、libtorch
  • 维护人员并不总是知道 CUDA 真实/虚拟架构如何工作
  • 某些项目没有默认的目标 CUDA arch
  • 链接的讨论是关于当上游项目没有默认值时应该针对哪些 CUDA arch，以及为了在 6 小时内完成构建，应该以什么顺序删除 arch
  • 我们能否为（feedstock）维护人员提供更好的关于应该针对哪些 CUDA arch 的指导？
  • 解决 6 小时以上构建时间的一些方案
    • 将 libtorch 构建 Python 扩展与 libtorch 分开（目前上游不支持；需要工作，不清楚需要多少工作，待询问）
    • 使用即将推出的 GPU 服务器在那里运行构建（没有时间限制）
    • 让 archspec 检测 CUDA arch 将使其中一些讨论变得毫无意义，并缓解 6 小时限制
      • 虚拟软件包使软件包的可移植性降低
  • 目前没有策略；暂时使用私有服务器；调查帮助 pytorch 分裂；查看 cudarchspec 软件包

推迟到下次会议

• (JK) Miniforge 23.10
• (JK) CUDA 11.8
• (JK) CUDA 12.x
• (JK) Conda + libmamba
• (JK) Quay 上 Alma 镜像的公开可见性
• (HV) 存档 k* 生态系统（请参阅此处的最后一条评论 here，有来自核心团队的五个 +1 赞）
  • 死气沉沉，一直是迁移的头痛问题
  • 存档是可逆的，所以我们最终咬紧牙关解决这个问题？
  • 如果有人想复活，可以在 feedstock README（或置顶问题）中留下说明；尽管这不太可能...
• (HV) error_overlinking: true 的迁移？
  • 已经在 staged-recipes 中为新的 feedstock 设置了，也应该推广到现有的 feedstock（最终）。
  • 这将是一个很好的机会来进行 {{ stdlib }} 相关的更改（例如，删除到 C/C++ stdlib 的隐式 run-export --> 必须在 recipe 中指定，error_overlinking 将找到缺失的实例；如果不是必需的，软件包依赖项将通过迁移而精简 🥳）

CFEPs

• [ ]