search

conda-forge / pynfft-feedstock

A conda-smithy repository for pynfft.
BSD 3-Clause "New" or "Revised" License
0 stars 6 forks source link

Numpy pinning #8

Open kohr-h opened 6 years ago

kohr-h commented 6 years ago

Since this package uses the Numpy C API, doesn't the recipe have to pin the Numpy version to the one it was built with? Like so:

  run:
    - python
    - {{ pin_compatible('numpy', max_pin='x.x') }}
grlee77 commented 6 years ago

I think it can be changed to use that notation, I just haven't update this recipe since that syntax became available.

The method currently in meta.yaml was the recommended way at one point. As long as the package builds against a NumPy that is not newer than the one the user has installed, it is fine (NumPy has a policy to maintain backwards ABI compatibility). I think those specific versions were the oldest with packages available for each python version/platform.

grlee77 commented 6 years ago

also, I should note that pyNFFT unfortunately no longer seems to be actively maintained and if I think it only works with NFFT 3.2.x.

kohr-h commented 6 years ago

As long as the package builds against a NumPy that is not newer than the one the user has installed, it is fine (NumPy has a policy to maintain backwards ABI compatibility). I think those specific versions were the oldest with packages available for each python version/platform.

Ah I see, makes sense. Then it's fine to build with 1.11, say, and not to require a specific Numpy version. AFAIK the current recommended way to do that is to specify numpy: 1.11 in conda_build_config.yaml and then use host: numpy {{ numpy }} and run: numpy in meta.yaml.

kohr-h commented 6 years ago

also, I should note that pyNFFT unfortunately no longer seems to be actively maintained and if I think it only works with NFFT 3.2.x.

Right, it hasn't been active in a while. There has been one commit to master, though, that makes pyNFFT build against 3.3 and higher. I tested updating the recipe with current Git master, and it seems to work with 3.4.1 (I haven't tested a lot of functionality).

I was considering a PR into pyNFFT to allow different dtypes, as upstream NFFT has support for single and long double since version 3.3 or so.