Defaults and conda-forge incompatibilities

This issue is created to remind that conda-forge and defaults have incompatibilities. To fix this, there are two ways.

1. conda-forge channel must have higher priority than defaults channel. To check, run conda config --get channels which gives you the channel priority order. conda config --add channels conda-forge would make conda-forge the highest priority channel.

2. When creating conda-forge packages, make sure the dependencies come from conda-forge. (There are few like libgcc that conda-forge is relying on defaults). If there’s a dependency missing in conda-forge, add them as well because this missing dependency pulled in from defaults might be relying on the behaviour of another package in defaults which would conflict with conda-forge.

[msarahan]

If you use conda-build 3’s pin_compatible functionality, a lot of this inter-channel incompatibility goes away, because the more intelligent constraints mean that you won’t actually be able to install incompatible software. Not that this is an immediate option, but more of a reminder that channel priority is not the end-all solution here. The better solution is for packages to capture enough compatibility information that mixing channels with confidence is actually possible.

[msarahan]

@guyer conda really does respect channel priority. Here you have features taking priority, though. Conda tries to minimize the number of features in an env. If you instead force a specific blas implementation (which is associated with a feature), you can get conda to avoid the MKL builds. Those are being chosen because they do not have a track_feature, whereas the openblas numpy stuff does.