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：不好，因為你無法區分手動輸入的值和模板輸入的值。

        *   Dont 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 中過濾掉 recipe 中未使用的項目（這樣矩陣維度就不會不必要地增加）

      *   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 users system at build time.
  
                  *   Stuart: were already not reproducible, and this bootstrap doesnt 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).