This issue is to track progress on an issue that has already spanned several PRs and issues. Since this issue has already spread across several PRs, this issue is being proposed to be the central discussion point, and any discussion on PRs should strictly be review of code, more than discussion of concepts.

The idea is that we need a better way of customizing recipes. When the numpy x.x style of pinning was added ( #573 ), people appreciated it, but wanted to generalize it. Jinja2 is already flexible enough, but we lack configuration schemes for reusable data, as well as some syntactic sugar to make configuration sufficiently easy.

Design goals:

• support config files at 3 levels, with lower levels overriding the upper ones:
  • included with conda-build
  • user's install-wide
  • per-package
• Identify key confiugration types:
  • pinning versions (versions that must match between build and run)
  • variants of a particular feature (BLAS: MKL/OpenBLAS/ATLAS/etc.)
  • Specifying compiler / toolchain options
• Specify how to distinguish builds: how do different variations end up with different filenames?
  • Probably can't just have all variations contribute to build string directly.
  • Hash instead? Installation would need to access metadata, not rely on build string

Current PR for implementation: #966

Past issues/PRs where much discussion has occurred:

• Using conda to manage multiple native library configurations without Anaconda or Python in the mix #911: @mwiebe suggests a batch/bash file-based approach to lining up compiler
• split off recipe render from build; recurse to find meta.yaml #908: @msarahan added conda render command, moving towards all version and recipe metadata being required to be present pre-build
• Build recipe parsing and extension #857 @kalefranz's proposal to add a separate jinja2 syntax for each jinja pass
• WIP: Build customization #848: @ukoethe's proposal to improve pinning
• Proposal: Use jinja2 templates to configure conda features automatically conda#1959: @ukoethe's proposal of customization of compiler, to enable non-standard Python distributions on Windows (to support C++11)
• [WIP] Resolve dependencies before build_id can be computed #747 @pelson's recommendation that build dependencies be resolved before build id is computed
• Support x.x for all dependencies. #728 @johanneskoester's generalization of the x.x syntax to all packages
• Change handling of numpy x.x so that it is only needed as a build requirement #653 @mwcraig's
• Lightened up the requirement on recipes to define numpy x.x as runtime #650 @pelson's proposal that the x.x numpy pinning syntax need only be in the run requirements, allowing the build requirements to be more meaningful (such as lower/upper bounds)
• Be more explicit when numpy version is included in dependency specs in metadata #573 @ilanschnell's original inclusion of the numpy x.x syntax