Rebuilt for numpy 1.14 and scikit image 0.13

[hmaarrfk]

No description provided.

[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.

[jakirkham]

Thanks @hmaarrfk. So this should be compatible with numpy 1.14 already. Are you seeing some sort of error? Details would be most welcome. :)

[jni]

@jakirkham it looks like a whole bunch of deprecations in the tests, e.g. the scipy atol= problem that we fixed recently in master. Can this be merged and built despite these deprecations?

See log here: https://circleci.com/api/v1.1/project/github/conda-forge/scikit-image-feedstock/124/output/105/0?file=true

[hmaarrfk]

@jakirkham well i was just trying to get travis to pass tests for scikit-image .14 and the numpy incompatibility problem came up while talking to @jni

We noticed that there was no conda build for np1.14 so I tried to build one. And alas.

[hmaarrfk]

The major PR on v0.13.x was just accepted.

Waiting on the version bump. Conda really complains when you don't change the version number.

[jakirkham]

We noticed that there was no conda build for np1.14 so I tried to build one.

Right so how we build things against numpy has changed in conda-forge. Namely we build against the oldest version of numpy we want to support and allow installation at runtime with that version of numpy or any newer one. This recipe appears to already be using an earlier (though still functionally equivalent) form of those changes. So it should be possible to install in a NumPy 1.14 environment already. In fact we already do this at our work.

Can this be merged and built despite these deprecations?

We could merge it, but as CIs are failing the builds won't upload. It sounds like we should either take patches from upstream and apply them here or publish a new patch release (if one is available).

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

[hmaarrfk]

@jakirkham my understanding was that you couldn't simply update the numpy version without recompiling packages as some things depended on compiler specific numpy options.

In either case, @stefanv just accepted a PR that allows the CI's in scikit-image to build sucessfully.
I just submitted a new PR to bump the version asking somebody with authority to create a new tag.

The new tag will allow the recipes to run with the most updated versions. Currently, they are pinned on 0.13.1

[jakirkham]

We use to use numpy x.x, which would pin packages to the major-minor version of numpy they built with at run time. After discussion, we decided to relax this generally in conda-forge and relaxed this for scikit-image specifically in PR ( #12 ) (that PR links to the doc update PR on the webpage).

Updating scikit-image would certainly be welcome. Happy to help however I can. :)

[jni]

@jakirkham I'm confused then about why this fails?

 $ conda create -n skimver -c conda-forge --override-channels python=3.6 numpy=1.14 scikit-image=0.13.1
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

  - scikit-image=0.13.1
  - imageio[version='>=2.1.0']
  - numpy
  - blas==1.1=openblas
  - openblas
  - libgfortran
  - scikit-image=0.13.1
  - imageio[version='>=2.1.0']
  - numpy
  - *[track_features=blas_openblas]
  - scikit-image=0.13.1
  - matplotlib[version='>=1.3.1']
  - scikit-image=0.13.1
  - pywavelets[version='>=0.4.0']
  - scikit-image=0.13.1
  - scipy[version='>=0.17']
  - libgcc
  - numpy=1.14
  - blas==1.1=openblas
  - openblas
  - libgfortran
  - numpy=1.14
  - *[track_features=blas_openblas]

Current channels:

  - https://conda.anaconda.org/conda-forge/linux-64
  - https://conda.anaconda.org/conda-forge/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

    https://anaconda.org

and use the search bar at the top of the page.

[jakirkham]

So -c conda-forge --override-channels means that defaults is dropped as well and only conda-forge is used. However we get libgfortran and libgcc from defaults on Linux. Changing the syntax as shown below works.

$ conda create -n skimver -c conda-forge -c defaults --override-channels python=3.6 numpy=1.14.3 scikit-image=0.13.1 blas

[jni]

Working with conda is a great way to understand why pip doesn't handle complex dependency chains. =P

fwiw I personally would love the day when defaults can be dropped, because it is such a pain in the ass to have to specify NumPy every time so that it doesn't get overridden by the mkl version for every little update of whatever.

[jakirkham]

To the best of my knowledge, pip doesn't have a dependency solver. I think they are trying to fix that, which would be good. Some discussion in issue ( pypa/pip#988 ).

So I think the blas story will get better after the rebuild with Anaconda's new compilers. There are some changes being made there that would basically make openblas the default for conda-forge. Also there is some discussion about supporting mkl in conda-forge, but it's still a bit early to say what will happen there.

Being able to totally drop defaults would require rebuilding the compilers as well. This is likely tricky without acquiring non-CI build resources. Though we are looking into that.

ref: https://conda-forge.org/docs/meta.html#compilers

[jakirkham]

Also if you are using conda 4.4.0+, you have the option of using MatchSpec. The docs are a little sparse (though it is pretty new). Basically this allows you to pin packages to particular channels, versions, etc. This is because conda now knows how to track requested packages, which is an awesome feature. Basically if you explicit call conda install with some constraints those are pinned in your environment (e.g. conda install conda-forge::blas). Good description of this in the changelog.

ref: https://github.com/conda/conda/releases/tag/4.4.0

[jakirkham]

Are we ok to close this?

[jni]

Yep. Thanks for the attempt, @hmaarrfk!