跳到主要内容

2016-06-03

时间：14:00 UTC

Hangout 链接： https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

参会人员

Ray, Matt, Jonathan, Phil, Jonas, Michael, Philippe, John, Bjorn Gruning, Jan

常设议题

  • 有多少仓库？
  • 有多少贡献者？
  • 新的核心开发者？

议程

  • PyPI 元数据冗余

  • Python3 vs Python==3

  • 如何从 Python==2 环境依赖（包括构建依赖）需要 Python 3 的应用程序

  • “子环境依赖”是一种可能的替代方案

  • 添加 soname 意味着共存。这并非总是可行。在这些情况下添加 soname 吗？

  • 引导：有时需要较旧的依赖项来构建当前事物（循环依赖也可能需要子环境）

  • Conda 构建以获得拆分构建

    *   runtime packages will have sonames
    • dev 包不会 - 它们将有版本。这强制互斥。给定 dev 包的版本，然后适当地确定运行时依赖项 soname。

  • 子环境黑客马拉松在 SciPy 2016（7 月 11-17 日）提出

  • 底层打包

  • NetCDF（也包括 curl/ca-certificates 和 Perl 包）- 完成了吗？

    *   curl and ca-certificates are done and available.

    *

    • Perl 不再与此过程相关

  • GitHub 速率限制。我们如何进一步缓解这些？

  • 为包添加命名空间 `node-`、`ruby-`、`perl-`，为什么不 `python-` ;-)
    • “实用性胜过纯粹性” ;-)
    • 至少一开始是这样，但我发现这并非普遍适用。
    • Continuum 提出的其中一个想法是主命名空间的概念 - 有效地定义了包的命名空间默认前缀。这可能是两全其美的方法。您也可以有排序优先级：首先搜索 python-*，然后搜索 node-*，最后搜索没有前缀的完整包名称。此优先级可能由每个环境的 condarc 定义，初始设置取决于安装的包。例如，首先创建安装了 python 的环境将使 python 成为主环境。
    • 我可以理解这种吸引力，但这似乎是造成相当大混乱的潜在根源（例如，为什么在此环境中安装 x 与在彼环境中安装 x 的工作方式不同？）。如果命名空间实际上是新语法的一部分，而不是仅仅是包名称的前缀，那么这可能会更可行。
    • 当然，这是合理的 - 让命名空间搜索成为用户定义的便利功能，而不是自动确定的功能。
    • 值得记住的是，Python 命名更改将是对现有 Continuum 包的重大突破。因此，不应轻率做出此决定。

  • 这里要考虑的另一件事可能是新的元数据。例如，我们可以指定包的主要语言。然后，我们可以指定 `conda install` 我们想要包的这种语言。可能的语法可能包括类似于上述语法的语法。不确定如果我们想要报错、警告并安装所有内容或其他内容，我们希望如何处理冲突。

  • 一个更简单的想法，我们可以考虑一下，它包括 Michael 上面提到的一些想法，但是可以在不更改 `conda` 或包元数据的情况下实现，那就是将包放在标记的通道中。这样，所有 Python 包都将位于 `conda-forge/label/python` 中。这样，人们可以简单地添加此标记通道并获得所有想要的 `python` 包。在启用多个标签时，它仍然有点脆弱，但也许这可以利用 Michael Grant 已经完成的通道解析工作。

  • PR 审查

    *   Treat every PR as a Work in Progress. At least let PRs sit for a few hours before merging them.
    • 当我们提出澄清问题时，等待答案，并在获得答案之前避免采取行动。
    • 尊重第一位审查员，不要用另一种语言重复她/他的审查意见。这对提交 PR 的人来说也是不利的，因为它会造成混淆。
    • 避免千刀万剐：许多小的“吹毛求疵”评论可能会吓到新的贡献者（ping Mike S ;-)

  • 通知（我们如何掌握它们）

  • 更多编译器乐趣

  • MSYS2

    *   Discussing Ray Donnelly's work on MSYS2 packages and how we want to use and integrate these into conda-forge.
    • 一些需要考虑的用例：OpenBLAS、FFTW、构建工具等？

  • 二进制数据

    *   Do we include it in recipes?
    • 如果允许，我们允许哪些类型（例如，图标）？
    • 我们如何验证许可？
    • 我们如何验证它们的安全性？

  • OpenBLAS（在 Windows 上）

  • Dev 版本：它们在哪里发布？

    *   Do we do them at conda-forge?

            *   Maybe add a label.

    *   Do we let others do them with a feedstock on their own repo?
    • 我们如何强制执行我们决定的任何事情？

  • Conda-forge 安装程序

    *   We have Python 3.5 now
    • 仍然需要 `conda`。
    • 新仓库？
    • 我们在哪里托管安装程序？Git 标签？

  • GitHub 速率限制。我们如何进一步缓解这些？

    *   GitHub letter ( [](https://docs.google.com/document/d/19HLtYPwg6IKAwmxPwL7Vd3AX0n47ANP-ZTpZROn-Cwc/edit?pref=2&pli=1)[https://docs.google.com/document/d/19HLtYPwg6IKAwmxPwL7Vd3AX0n47ANP-ZTpZROn-Cwc/edit?pref=2&pli=1](https://docs.google.com/document/d/19HLtYPwg6IKAwmxPwL7Vd3AX0n47ANP-ZTpZROn-Cwc/edit?pref=2&pli=1) ).

  • 频道镜像。

  • Feedstock 历史

    *   Is it sacred?

    • 我们是否进行 rebase/强制推送？

          *   If so, under what conditions?
      • 我们如何避免多人同时执行此操作？

  • 考虑申请成为 Numfocus 赞助的项目。

  • 以 SONAME 命名原生库包 -> conda forge/conda forge.github.io#157

  • Continuum 元数据请求：我们可以将这些添加到 linter 吗？

    *   example metadata: [](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)[https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)
    • 此外，区分摘要（限制为 77 或 80 个字符）和描述（无限制）

  • Google Hangouts 的最大容量为 10 人。是否值得考虑其他沟通方式，以便每个想参与的人都可以参与？

笔记

自上次会议以来 3 周

587 个仓库，105 位贡献者（但有些是机器人）

建议将 Patrick Snape 添加为核心开发者

PyPI 元数据冗余

Jinja 模板可能适合从 PyPI 元数据中填充此数据

关于如何维护纯 Python 包的 conda 包的问题，建议使用现有的 feedstock 设置。似乎所有在场的人都同意这一点。

PyPI RSS/Twitter 检查新版本

GitHub 发布版本的 Atom feed

按 soname 命名库包

libpng16/17，必须更新和重新编译 pinning 可能会导致问题。

建议将包名称更改为 soname（libpng16、libpng17 等），然后多个版本更改

头文件呢，它们是无版本的。

我们可以在单个环境中安装同一库的多个版本吗？

将 dev 包（带有头文件）从库中分离出来？

我们可以按版本号跟踪头文件吗？

当我们将同一库的多个版本加载到内存中时，符号解析是否有效？-- 可能无效

隐藏系统库可能会导致问题

devel 包将是互斥的、版本化的

库包按 soname 命名

需要确保同一库的两个版本的头文件不能被引入到同一个构建环境中，否则会导致问题

conda build 需要支持拆分包，良好的测试用例

决定

  • 将 soname 添加到运行时包
  • dev 包将是版本化的，但不包括 soname
  • 任务：Jan 将写下 libpng soname 命名的提案 -> conda forge/libpng feedstock#7
  • 任务：在 conda-build 中拆分包，在仓库中打开 issue

Python 3 vs python==3

“子环境”，允许在同一环境中访问 Python 2 和 3。

我们是否希望能够在同一环境中拥有多个运行时

真的不想这样做，conda 环境很便宜

子环境对于引导自托管编译器是必需的。也许在 SciPy 上讨论/研究这个问题

与 NumFocus 的关联

需要三名没有共同隶属关系的成员

可以获得非营利组织地位

为更大/更长的构建服务提供资金

Qt 构建和其他长时间构建

也可以使用 Travis/其他工具来延长构建时间

如果能拥有我们自己的服务器就好了

Rackspace 与 NumFocus 合作并提供免费 VM 时间

向更广泛的社区寻求帮助，服务器、包托管等

向包添加命名空间

这应该是一个要求吗？

以语言为前缀

文件夹？

numpy 呢，应该叫 python-numpy 吗

安装时呢？

  • conda install python-numpy python-scipy？

这将需要更改 conda

警告

为所有非 python 包添加前缀

仅依赖包，pandas 依赖于 python-pandas

GCC

配方是否应该用编译器和版本进行注释

仅检查版本的 gcc 包

gcc dev 包真的很神奇

conda-forge docker 镜像 (https://github.com/conda-forge/docker-images/tree/fbde090bd608caa720d5caad861aa382a8bf3f5c/linux-anvil )

讨论编译器的特别会议（也包括 MSYS2？）

  • 下周四 14:00 UTC（6 月 9 日星期四）
  • 查看彼此的 docker 镜像

下一次全体会议在三周后

  • 14:00 UTC（6 月 24 日星期五）

SciPy，BOF，冲刺，第一天的闪电演讲

  • 我想准备一个快速介绍“如何 conda-forge”，展示从 staged-recipes 到更新 feedstock 的工作流程。可以在 BOF 中或作为另一个闪电演讲。（最好在 Jonathan 的 LT 之后。）