Remove numpy 112 exclusion

[kyleabeauchamp]

cc @fonnesbeck

I don't know if this is permissible or not. There were some reports of issues with np112 on Windows, but I'm not certain that those reports were observed on non-windows platforms.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ocefpaf]

@kyleabeauchamp what is the minimum version of numpy? If it is numpy 1.11 you can do:

build:
  numpy 1.11.*
run:
  numpy >=1.11

and then re-render. If you want to support more numpy versions see https://github.com/conda-forge/netcdf4-feedstock/blob/master/recipe/meta.yaml for an example of the lower limits we have in conda-forge at the moment.

[kyleabeauchamp]

I would think that anything above 1.8 would work (https://github.com/pymc-devs/pymc/blob/master/pymc-requirements#L2). Do we need to add one line for every possible numpy version or does the current recipe work.

[ocefpaf]

I would think that anything above 1.8 would work (https://github.com/pymc-devs/pymc/blob/master/pymc-requirements#L2).

Nice!

Do we need to add one line for every possible numpy version or does the current recipe work.

For that scenario you can use exactly the combination in the recipe I sent to you above. The goal is to build with the oldest numpy possible/available and then run with any versions that is backwards compatible.

Note that we don't have numpy 1.8 everywhere and that is why we use 1.9 or 1.11 for some Windows+Python combinations.

[kyleabeauchamp]

What about numpy 1.12? That recipe doesn't list it.

[ocefpaf]

What about numpy 1.12? That recipe doesn't list it.

That is exactly my the point above! If you build with numpy 1.8.* and add numpy >=1..8 to run you'll be able to use any version that is >=1.8 (1.12 is >= than 1.8). Just bare in mind the caveat I mentioned above regarding the numpy versions available to build against.

[kyleabeauchamp]

Updated with numpy grid from netcdf4

[ocefpaf]

OK. Now you need to bump the build number, so a new package gets created, and then you'll need to rerender. See https://conda-forge.org/docs/conda_smithy.html for the instructions on re-rendering.

[kyleabeauchamp]

I'm concerned about removing the numpy x.x. This package compiles fortran code that interacts with numpy, which to me means that we need to build a separate build for each numpy version.

[ocefpaf]

I'm concerned about removing the numpy x.x. This package compiles fortran code that interacts with numpy, which to me means that we need to build a separate build for each numpy version.

https://conda-forge.org/docs/meta.html#building-against-numpy

Also, see my comment above regarding backwards ABI compatibility.

[kyleabeauchamp]

Updated the build number, but I can't seem to get either conda smithy rerender or conda-smithy rerender working. Seems like the executable is not installed. I'm in the root env, FWIW.

[ocefpaf]

That is odd. I can do that for you then. Hold on...

[isuruf]

Updated the build number, but I can't seem to get either conda smithy rerender or conda-smithy rerender working. Seems like the executable is not installed. I'm in the root env, FWIW.

@ocefpaf, can this be an issue with noarch? @kyleabeauchamp what's the version of conda-smithy you are using? (You can check by running conda list)

[kyleabeauchamp]

conda list|grep smith
conda-smithy              2.4.0                      py_1    conda-forge

[kyleabeauchamp]

PS: I would like to wait for @fonnesbeck to reply before we push this update live, as he is the primary maintainer of pymc.

[ocefpaf]

@ocefpaf, can this be an issue with noarch?

Don't think so, I've been using it non-stop without a problem since the release.

[ocefpaf]

Closing this in favor of #3