2016-05-09 关于构建自定义的特别会议

14:00 UTC

环聊链接：???

与会者：Michael Sarahan、Ray Donnelly、Kale Franz、Michael Grant、Ullrich Koethe、Stuart Berg、Phil Elson、Mark Wiebe

议程/会议纪要

版本参数化

*   MichaelS:  proposing to have dependency resolution become part of meta.yaml  rendering.  May require extra (3rd) jinja rendering pass.

需要在 Jinja 模板完全表达之前知道依赖关系（#747 中的主要问题）

Phil：不好，因为您无法区分手动输入的值和模板化的值输入。

    *   Dont know which ones are important for build string

            *   Build strings only matter when we have a build matrix; there to disambiguate
*   MichaelS proposes manual specification of entries in build string
*   Ullrich: if build strings just disambiguate, why not use hash?

                    *   MichaelS: hash fine, but needs to be reproducible.

    *   Heart of issue is that matrix build tools need some way to understand what parameterizes the build matrix.

            *   MichaelS  offered that no matter what solution we settle on, there will be  something readily inspectable.  Maybe this can feed into automatically  creating the build string.

如果需要 recipe-local config.yaml，Kale 询问为什么不直接将其包含在 meta.yaml 中

*   Not  sure what use case necessitates recipe-local config.yaml (global one is  agreed upon by all).  MichaelS OK with meta.yaml modifications if need  be.

Phil 指出，全局 config.yaml 可能仍然需要代码更改才能适应新版本的 Python。

*   MichaelS  says no, theres surely ways we can express things like latest 2  versions - just question of how to technically achieve.

Ray：从全局 config.yaml 中过滤掉配方中未使用的内容（以便不会不必要地添加矩阵维度）

*   Ullrich:  However, one must be careful to not filter out indirect dependencies  that are not explicitly named in meta.yaml, but were intentionally added  to config.yaml. (example: meta.yaml lists h5py as a requirement, and  config.yaml restricts the indirect hdf5 dependency to a particular  variant of the hdf5 package). It is safer to err on the too much side.

构建环境规范

*   Conda-build 848 has bootstrap environment: user creates an env, that env is captured as build requirements for another recipe.

        *   Phil: this ruins reproducibility, since it depends on the setup of the users system at build time.

                *   Stuart: were already not reproducible, and this bootstrap doesnt make things worse.
    *   MichaelS:  if this is used to hard-pin build-time dependencies, it may actually  help reproducibility.  Hard-pinnning at build time is orthogonal to this  PR, but may be easier to achieve with it.
    *   Ullrich:  if the contents of the build environment are recorded in index.json,  one can recreate the bootstrap environment at any time (or equivalently,  create config.yaml from that information), subject to the degree of  accuracy of the recorded data (e.g. are the source channels recorded, or  only version numbers and build strings?)

        *   MichaelS,  Kale concerned that people may include too many unnecessary packages in  build requirements this way, out of carelessness or ignorance

                *   Ullrich: not a big deal - runtime dependencies are what really matter.

编译器自定义

*   Mark: 848 is OK, but how does it address compiler and build flags?

Conda 1959 是构建标志的示例。在 bld.bat/build.sh 的开头使用 bat/sh 脚本。类似于 Mark 的努力。虽然不喜欢必须添加额外的 shell 脚本 - 但想要原生支持
```
    *   MichaelS  offered integration with conda-build, when use cases are better  understood.  Some kind of hook to call standardized setup script.
```
- Ullrich：重要的方面是，conda-build 用户应该可以轻松指定要使用的设置脚本。在引导环境中安装专门的构建包似乎是一个简单的解决方案（例如， conda create -n my_bootstrap_env visual-studio-build=12.0 或 conda create -n my_bootstrap_env visual-studio-build=12.0.debug ）
- Ullrich 指出，这些软件包还需要排除与其他软件包一起使用，因为它们不兼容
Mark：希望创建一个易于使用的 http://vfxplatform.com/ 的 conda 实例。希望在我们解决该功能时参与其中。

Ullrich：最终解决方案（无论它是什么）的关键要求

    *   Build dependency customization must be possible for _any_  package, although it would be OK if it were a bit more complicated for  the less common situations. It is crucial to support two cases:

            *   Customize _indirect _dependencies not specified in meta.yaml.
*   Narrow dependencies listed in meta.yaml (e.g. python 3.* => python 3.5.*).

    *   Run  requirements must be specialized during the build such that version  resolution will only select compatible variants, even if active channels  offer newer, yet incompatible variants (right now I usually use -c  ukoethe --override-channels, but this is a pain).