Be more explicit when numpy version is included in dependency specs in metadata

[ilanschnell]

Currently, it is only possible to create a conda package, that just depends on numpy, by unsetting CONDA_NPY (and not using the --numpy option). One can build two different packages depending on this setting (outside the recipe), which is undesirable.
This PR makes the numpy version being included in dependency specs in metadata much more explicit. Listing just numpy as the runtime dependency, will always result in just that (setting CONDA_NPY won't change that. In order to make a recipe independent of the numpy version actually set, one lists numpy x.x as a dependency, which will require using CONDA_NPY or --numpy.

Also, we add a new function, handle_config_version() to handle the confusing logic, as well as tests for this new function.

[asmeurer]

@pelson I know you had some thoughts on this.

[asmeurer]

There are some tests that need to be fixed.

[asmeurer]

Looks like these were broken when we removed np from the build string. #576. The tests just need to be modified.

[pelson]

Perfect. This was one of the hard parts of me trying to remove the bit of conda-build which knows about python, numpy etc.

Next steps for me would be to try to have some form of automatic build string extension which does https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L431.

Incidentally, you might both be interested in my hacky way of defining a conda_build.metadata.MetaData which does not depend on the value of conda_build.config.CONDA_NPY: https://github.com/pelson/Obvious-CI/blob/master/obvci/conda_tools/build_directory.py#L93. With this, I was able to have a reference to more than one numpy meta which each having specific version dependencies.

[pelson]

Any clue what the special case is for?

[ilanschnell]

What special case? The new function handle_config_version() is full of special cases, which is why add separated it out, in order to write extensive tests for it: https://github.com/conda/conda-build/blob/master/tests/test_metadata.py#L34

[pelson]

...ms.name == 'numpy'):

The numpy part. It is the only place where a package name is important in the function.

[pelson]

Incidentally, I noticed there isn't a test for the '<name> x.x' with version as None case in those tests. Can that ever occur?

[asmeurer]

I agree it shouldn't be special-cased.

[ilanschnell]

Well if we don't special case numpy, i.e. make requiring the x.x when the version is important, then every time you have a python dependency, you have to say python x.x, which would break almost all existing recipes.

[rmcgibbo]

Can you give any guidance on how to reformat recipes that build against the numpy C API to work as they did before (that is, being built against particular versions of numpy, and having that numpy version reflected in the build string like np19py34 or whatever)? I change

requirements:
  build:
    - numpy
    [ ... ]

to

requirements:
  build:
    - numpy x.x
    [ ... ]

but this doesn't appear to set the build string -- for example conda-build --numpy 1.8 bhmm gives a package named bhmm-0.5.1-py27_0, not bhmm-0.5.1-np18py27_0. Is it also necessary to manually change the build string as well?

[newlawrence]

I use the following workaround (needs the CONDA_NPY to be set, I've not tested it with the --numpy flag):

    - numpy 1.9*  # [np == 19]
    - numpy 1.10* # [np == 110]

It's the only way I've found to bind the environment variable with the specified version. With that solution the build string also works as expected including the NumPy tag.