跳转到主要内容

conda-forge 核心会议 2024-01-24

在 `您的 __new__() 议程项目` 标题下添加新的议程项目

参会者​

姓名首字母GitHub ID隶属关系
Jaime Rodríguez-GuerraJRGjaimergpQuansight/cf
Michael SarahanMCSmsarahanNVIDIA/CF
Marius van NiekerkMvNmariusvniekerkVoltron Data/CF
Cheng H. LeeCHLchenghleeAnaconda/CF

总共 12 人

常设议题​

  • [ ]

来自之前的会议​

  • [ ]

正在进行的投票​

  • [ ]

您的 __new__() 议程项目​

  • (HV) 我们如何引入 `{{ stdlib("c") }}`？
    • 设计异议已撤回，功能已在 conda-build 3.28 中发布。
    • 主要问题是如何广泛推广此更改。我建议暂时将其范围严格限制在 C stdlib 中（尽管如果我们愿意，将其与专门针对 `error_overlinking: true` 的迁移联系起来仍然是一个选项）。
    • (IF) 认为我们应该有一个迷你迁移器（搭载），这样我们就不必重建所有 C/C++ 包；仅在必要时重建。
    • (MvN) 同意我们应该对迁移采取懒惰的方法；也许可以列出一些急于迁移的软件包
    • (MvN/IF) 我们可以安全地假设 “世界是平的” -> 依赖包也不需要迁移。
  • (HV) 迁移 boost 1.84？
    • 最近我们迁移了 boost 的每 4 个版本；以前更频繁（每两个版本）。一位核心成员 (Uwe) 建议迁移到 1.84；我认为值得这样做。
    • 在 1.82 的重大重构之后（分离出仅头文件的库，添加 run-export），现在迁移应该更容易了。
    • (IF) 我们应该收集/审查关于执行 boost 迁移需要多长时间的数据，并用它来判断我们应该多久更新一次。例如，如果需要 3 个月，那么也许一年一次是合理的；如果需要 1 个月，那么每六个月一次？
  • (KE) 我们可以创建一个 sccache 存储来减少构建冗余吗？
    • (MvN) 最大的问题是，“我们把缓存放在哪里？”
      • (MCS) 我们在 MSFT 或其他云提供商那里有可以交谈的联系人吗？
    • (MvN) `conda-build` 行为使缓存复杂化；例如，如果不小心，构建环境名称中使用的时间戳可能会泄漏到缓存中
    • (IF) 我们什么时候需要 sccache？例如，构建不同的构建编号与 [上游] 版本是否会从缓存中受益？
    • (MCS/KE) Nvidia 的观点是 Rapids 无法进入 conda-forge，因为它构建时间太长。正在探索 sccache 是否能使 conda-forge 发行变得可行。
      • (IF) 使用 Quansight 托管的构建器可能是一个选项
      • (KK) 构建所有 Rapids 可能比 PyTorch 或 TensorFlow 更大的工作。可能还需要考虑拆分为每个设备的架构构建
    • (MCS) 需要明确的动机通过 c-f 分发 Rapids；否则不想使 c-f 基础设施过载
      • (KK) 目前无法 [轻易地] 依赖 cuDF、cuML

推迟到下次会议​

  • [ ]

CFEPs​

  • [ ]