Unexpected behavior with conda environment, maybe due to channel priority.

[pierrepo]

Bug description

While building an environment with this conda env file. I encountered the following error:

Encountered problems while solving:
  - package python-3.7.12-hb7a2778_100_cpython requires libffi >=3.4.2,<3.5.0a0, but none of the providers can be installed

pkgs/main/noarch          
pkgs/r/noarch             
hcc/linux-64              
pkgs/r/linux-64           
hcc/noarch                
pkgs/main/linux-64        
conda-forge/noarch        
conda-forge/linux-64      
time: 20.902
Removing intermediate container d764b8b287a2
The command '/bin/sh -c TIMEFORMAT='time: %3R' bash -c 'time ${MAMBA_EXE} env update -p ${NB_PYTHON_PREFIX} --file "binder/environment.yml" && time ${MAMBA_EXE} clean --all -f -y && ${MAMBA_EXE} list -p ${NB_PYTHON_PREFIX} '' returned a non-zero code: 1(

Expected behaviour

I would expect the environment to build without error. This is the case when removing the 2 last lines of the file environement.yml:

  # https://anaconda.org/hcc/octave-struct
  - octave-struct

If the environment failed to build, I would expect an error related to the package octave-struct that it the last new package introduced in the environment file.

Please note octave-io and octave-struct conda packages are provided by the hcc channel.

Actual behaviour

My environment failed to build and I got an error related to libffi >=3.4.2,<3.5.0a0. It is strange because libffi 3.4.2 is provided by conda-forge.

My guess is that there is something weird going on with channels (but not really sure about it).

How to reproduce

1. git clone https://github.com/plasmabio/template-octave.git
2. cd template-octave
3. jupyter-repo2docker .
4. You should obtain the same error.
5. Remove the 2 lines of binder/environment.yml
6. You shouldn't get any error.

Your personal set up

• OS: Linux Ubuntu 20.04.5 LTS
• Docker version: Docker version 20.10.17, build 100c701
• repo2docker version : 2022.02.0+19.g1d218af

[bollwyvl]

Two things:

• channels is an ordered list (first wins)
  • mixing conda-forge and.... anything that doesn't think about conda-forge such as pkgs/main probably won't work
• dependencies is a set
  • the order doesn't matter
  • this set is updated against a baseline environment, if possible, and then re-computed
  • if it fails, it fails as a set

Some things to try:

• channels
  • try explicitly opting out of the ToS-encumbered pkgs/main, etc. with the "magic" nodefaults channel
• dependencies
  • if possible, encourage the hcc maintainers to
    • use the conda-forge-pinnings when building
    • shed any possible packages into conda-forge through the staged-recipes workflow
      • bioconda has had success taking this approach, reducing their overall maintenance burden, and being more able to handle e.g. new architectures, platforms and runtimes