2020-08-19 conda-forge 核心会议
与会者
议程
常设项目
- 为通话中的新人介绍
- (CJ)预算
您的新议程项目
-
(ED)@sylvain:OVH 上 Windows VM 的任何更新?
-
(AS)qgpu - GPU 构建代理。
- Drone 还是 Azure?Drone 是一个简单的 go 可执行文件,您可以在 docker 中运行它。Azure 构建代理是否很重?
- 选择一个并开始
-
(CJ)版本提升提供依赖关系分析作为提示
- 为机器人提供提示系统,根据源代码分析,我们认为依赖关系应该是什么
- 目前使用 depfinder。仅适用于 Python。
- 已分析约 6000 个软件包
- 对于 30% 的软件包,depfinder 和 CF 元数据一致
- https://github.com/regro/cf-scripts/pull/1126
- https://github.com/regro/cf-graph-countyfair/tree/master/audits/depfinder
- https://github.com/regro/cf-graph-countyfair/blob/master/audits/depfinder/_net_audit.json
- 我们可以为 C 软件包执行此操作吗?
- 构建后步骤会对创建的 DSO 执行某些操作。不能提前执行。您可以在构建后检查。
- (CJ)C 构建可以发布此信息吗?
- (JJ)也许?
- (FF)如果依赖项在构建时不存在,C 构建将失败。Python 则不会。
- 我们可以为 R 执行此操作吗?
- 从 CRAN 获取元数据并更新
- 使用 skeleton 获取 R 依赖项。Grayskull 尚不处理 R 配方。
- 软件包数量:6k 是 Python,2k 是 R。在这两者之间,我们将覆盖 80% 的生态系统。
- (MB)我们应该如何处理信息丢失?可选依赖项 - 也许作为 meta.yaml 中的注释捕获?依赖项的版本边界?
- 可选依赖项 - 在信息额外部分捕获
- (CJ,补充)conda-forge、pypi 和导入之间的映射:https://github.com/regro/cf-graph-countyfair/blob/master/mappings/pypi/name_mapping.yaml
- 请注意,映射是不完善的,因为它依赖于 conda-forge
test: imports:
元数据。 - 如果我们能直接从软件包/源代码中获取它就好了
- 请注意,映射是不完善的,因为它依赖于 conda-forge
-
(KK)conda-forge 中的 cudatoolkit 软件包
- 仍然只发布每个 EULA 可再发行的部分(共享库)
- nvbug #: 3052604
- 用于跟踪这些类型审批的 NVIDIA 内部系统
- 链接(仅在 NVIDIA 内网中有效):http://nvbugs/3052604/
- (KK)批准在 conda-forge 中托管与 defaults 上相同版本的 cudatoolkit
- 也许不要只是从 defaults 复制配方。或者至少重新审视
- 希望有一些 Nvidia 人员维护配方。随着时间的推移将其迁移到 Nvidia 的 CUDA 团队。
- (JK)也许使用变体在一个分支中维护所有版本
- (JJ)cudnn 怎么样?我们可以将其移至 CF 吗?
- (KK)所有 cuda 库都应该可以从 CF 发货。只要我们可以通过预链接或后链接显示 EULA 即可。NVIDIA 内部可以接受仅将其作为预链接脚本消息传递机制。
- (IF)您是否考虑过拆分配方,让所有不同的库最终都位于不同的 conda 可安装单元中?
- (KK)是的,那是长期计划。我们正在尝试做 Windows 方面的工作。他们的团队主要专注于 Linux。
- (JJ)如果我们最终确实要进行 Windows 开发,那么请确保我们拥有所有 Windows 版本。如果您只有一两个软件包可用,而不是 default 有很多软件包可用,那么严格的通道优先级是有害的。
-
(CHL)供您参考:conda 4.8.4 行为变更 --- 虚拟软件包约束现在强制执行
- 肯定会影响许多 CUDA 软件包(例如,在 CUDA 9.x 系统上不再能安装 CUDA 10 依赖的软件包);例如,https://github.com/conda/conda/issues/10152
- 将致力于解决求解器消息传递问题,因为错误通常是不透明且不相关的
- 有一个环境变量可以设置以更改 conda 对 cuda 版本的看法:CONDA_OVERRIDE_CUDA
上周未完成的内容
谁在负责这些行动项目?
- 放弃 python 3.6
- 需要一个公告周期
- 我们应该遵循 NEP29 吗?NEP29 + 6 个月?
- Python 3.x 版本的生命周期结束
- 3.7 没有 pypy
- 行动项目:发送到 issue(从 pypy 团队和其他人那里获取输入)
- (CJ)py36 应该保留到 pypy 发布(它即将到来)。那很快就会到来,所以不像我们一直在保留
- 待办事项:(ED)Python 版本
- 保留 3 个 Python 版本
- 随着社区的迁移而放弃旧版本(当 scipy、matplotlib、numpy 等迁移时)
- 如果我们需要(例如,pypy 还没有 py37),我们可以暂时保留一个旧版本
正在进行的投票
子团队更新
机器人
ARM
POWER
CUDA
文档
staged-recipes
网站
安全+系统
CI 基础设施
编译器升级
CFEP 更新
开放 PR
-
cfep-04 X11 和 CDT 政策
- 非活动 - 合并为某种非活动状态?
- 需要新的负责人。感谢您对此 pkgw 的工作!自 2020 年 1 月 10 日起,pkgw 提出了未解决的评论
-
cfep-06 Staged-recipes 审查生命周期
- 非活动 - 合并为某种非活动状态?
- 来自 @saraedum 的持续评论。@jakirkham,您可以回复吗?自 2020 年 1 月 8 日起,@saraedum 提出了未解决的评论
- (MRB)stalebot 已经解决了这里最糟糕的问题。我认为我们可以永久推迟这个问题。
-
cfep-10 Feedstock 状态,未维护
- 非活动 - 合并为某种非活动状态?
- 需要另一次审查。自 2020 年 1 月 11 日起,pkgw 提出了未解决的更新
-
cfep-12 删除违反源软件包条款的软件包
- 自 2020 年 5 月 26 日起停滞
- 关于移动到“broken”与从 conda-forge 频道删除的 активные обсуждения
- 正在进行的投票,于 2020-03-11 结束
- 投票结果是什么?
- 我们收到 NumFOCUS 的回复了吗?
-
cfep-17 处理 pin backports 和依赖项重建
- Isuru、CJ 和 Matt 之间关于实施细节的停滞辩论
- 2020-07-22 更新:我们原则上同意在临时基础上(即,直到迁移结束)直接在 feedstock 中渲染所需的额外 pinning。
讨论
检查之前的行动项目
从上次会议议程复制之前的行动项目。
本次会议
上次会议
2 次会议前
- 弄清楚如何向用户传达重大更改。可能应该立即打开一个 issue 以进行进一步讨论。Ping @kkraus,并从这些会议记录中捕获更进一步的笔记
- (Eric)待办事项:在 conda_forge.yaml 中将 strict 设置为选项,并默认开启。在 conda-smithy 中打开 issue
3 次会议前
- Eric 将在我们的文档中添加一个新页面,介绍如何以商业关系与 conda-forge 及其附属机构互动。
- Eric 将从 Keith 那里获取 NVBug 链接并将其存档在 conda-forge google drive 中。
- John K. 将更新 git repo 上的 cuda toolkit feedstock,以记录指向 NVIDIA 内部 issue 跟踪器的 NVBug 链接
- Jonathan 将更新文档,以记录一些非详尽的软件包列表(如 cuda-toolkit、MKL 等)
- Jonathan 将审查此 PR
移至 Issue Tracker
- (Kale)安排 conda 工作组
- cfep-10 后续步骤:CJ 调用投票以征求反馈
- cfep-06 后续步骤:要求 staged recipes 团队负责此 CFEP 并推进它
- jakirkham & CJ-wright 同步关于将 CUDA 添加到迁移机器人
- (Eric)安排 Anaconda <-> conda-forge 同步 anaconda.org 需求收集
- 将尝试在下个月安排此事。
- (Anthony)联系 NumFocus 以弄清楚文件中不包含许可证的法律后果。
- (Eric)内部检查社区人员的酒店和机票的资金水平?
- (Eric)弄清楚 conda-forge 的财务状况以支持自身?
- (jjhelmus)为我们将支持哪些 python 打开 CFEP
- (jakirkham)写一篇关于我们今天讨论的 CUDA 问题的博文
- (jakirkham)更新关于如何向 feedstocks 添加 CUDA 支持的文档
- (jakirkham)将在 conda-smithy 上打开一个 issue 以调查 Drone 问题。(ping aarch 团队)
- (ED)关于我们页面?FAQ 和每个人是谁的某种组合。FAQ 类似
- CF <> Anaconda、CF <> NumFocus、CF <> Azure 的 POC 是谁
- 各个子团队的 POC 是谁?
- 非正式信息:角色、日常工作、简历、所有细节,您为什么在这里等等。
- 公开还是内部?我真的不在乎。有人强烈倾向于其中一种吗?
- 选择加入公开简历
- 软件木工有大量讲师,网址为 https://carpentries.org/instructors
- 有人担心“又一个需要保持更新的地方”
- (CJ)组建财务子团队
- (ED)记录使用 conda-forge 的可重现环境的策略
- (UK)静态库问题
- 向构建添加 linting 提示以查找它们
- 推荐如何打包它们 -> CFEP-18
- 我们应该编写文档说明我们不提供支持,这是一个坏主意。 -> CFEP-18