v0.10.0 incompatible with python3.8 from defaults channel

[synapticarbors]

It seems as if the build for v0.10.0 is incompatible with the build of python3.8 from the defaults channel.

$ conda create -n test python=3.8.* pymysql=0.10.* --override-channels -c defaults -c conda-forge --strict-channel-priority

results in

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package python conflicts for:
pymysql=0.10 -> python
python=3.8
Note that strict channel priority may have removed packages required for satisfiability.

but giving priority to the conda-forge channel works:

$ conda create -n test python=3.8.* pymysql=0.10.* --override-channels -c conda-forge -c defaults --strict-channel-priority

gives:

Solving environment: done

## Package Plan ##

  environment location: /Users/xyz/miniconda2/envs/test

  added / updated specs:
    - pymysql=0.10
    - python=3.8

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    libcxx-10.0.1              |       h5f48129_0         1.0 MB  conda-forge
    pymysql-0.10.0             |     pyh9f0ad1d_0          42 KB  conda-forge
    python_abi-3.8             |           1_cp38           4 KB  conda-forge
    ------------------------------------------------------------
                                           Total:         1.0 MB

The following NEW packages will be INSTALLED:

  ca-certificates    conda-forge/osx-64::ca-certificates-2020.6.20-hecda079_0
  certifi            conda-forge/osx-64::certifi-2020.6.20-py38h32f6830_0
  libcxx             conda-forge/osx-64::libcxx-10.0.1-h5f48129_0
  libffi             conda-forge/osx-64::libffi-3.2.1-h4a8c4bd_1007
  ncurses            conda-forge/osx-64::ncurses-6.2-hb1e8313_1
  openssl            conda-forge/osx-64::openssl-1.1.1g-h0b31af3_0
  pip                conda-forge/noarch::pip-20.1.1-py_1
  pymysql            conda-forge/noarch::pymysql-0.10.0-pyh9f0ad1d_0
  python             conda-forge/osx-64::python-3.8.5-cpython_h85f3143_0
  python_abi         conda-forge/osx-64::python_abi-3.8-1_cp38
  readline           conda-forge/osx-64::readline-8.0-h0678c8f_2
  setuptools         conda-forge/osx-64::setuptools-49.2.0-py38h32f6830_0
  sqlite             conda-forge/osx-64::sqlite-3.32.3-h93121df_1
  tk                 conda-forge/osx-64::tk-8.6.10-hbbe82c9_0
  wheel              conda-forge/noarch::wheel-0.34.2-py_1
  xz                 conda-forge/osx-64::xz-5.2.5-h0b31af3_1
  zlib               conda-forge/osx-64::zlib-1.2.11-h0b31af3_1006

Since pymysql is a pure python package with no dependencies, I'm surprised that there is a conflict. Any ideas about what might be going on? I know that it can be problematic to mix packages form different channels, but typically if you use defaults as the primary channel and then only fall back to conda-forge for pure-python packages it works (or at least in the past it did).

@conda-forge/core

[wolfv]

Mamba gives you an appropriate solution:

Looking for: ['python=3.8', 'pymysql=0.10']

Transaction

  Prefix: /home/wolfv/miniconda3/envs/asdn123

  Updating specs:

   - python==3.8
   - pymysql==0.10

  Package                Version  Build         Channel                  Size
───────────────────────────────────────────────────────────────────────────────
  Install:
───────────────────────────────────────────────────────────────────────────────

  _libgcc_mutex              0.1  main          pkgs/main/linux-64     Cached
  ca-certificates      2020.6.24  0             pkgs/main/linux-64     Cached
  certifi              2020.6.20  py38_0        pkgs/main/linux-64     156 KB
  ld_impl_linux-64        2.33.1  h53a641e_7    pkgs/main/linux-64     568 KB
  libedit           3.1.20191231  h14c3975_1    pkgs/main/linux-64     116 KB
  libffi                     3.3  he6710b0_2    pkgs/main/linux-64      50 KB
  libgcc-ng                9.1.0  hdf63c60_0    pkgs/main/linux-64     Cached
  libstdcxx-ng             9.1.0  hdf63c60_0    pkgs/main/linux-64     Cached
  ncurses                    6.2  he6710b0_1    pkgs/main/linux-64     Cached
  openssl                 1.1.1g  h7b6447c_0    pkgs/main/linux-64       3 MB
  pip                     20.1.1  py38_1        pkgs/main/linux-64       2 MB
  pymysql                 0.10.0  pyh9f0ad1d_0  conda-forge/noarch      42 KB
  python                   3.8.3  hcff3b4d_2    pkgs/main/linux-64      49 MB
  readline                   8.0  h7b6447c_0    pkgs/main/linux-64     Cached
  setuptools              49.2.0  py38_0        pkgs/main/linux-64     737 KB
  sqlite                  3.32.3  h62c20be_0    pkgs/main/linux-64       1 MB
  tk                      8.6.10  hbc83047_0    pkgs/main/linux-64       3 MB
  wheel                   0.34.2  py38_0        pkgs/main/linux-64      51 KB
  xz                       5.2.5  h7b6447c_0    pkgs/main/linux-64     341 KB
  zlib                    1.2.11  h7b6447c_3    pkgs/main/linux-64     Cached

  Summary:

  Install: 20 packages

  Total download: 59 MB

───────────────────────────────────────────────────────────────────────────────

[synapticarbors]

Actually I tried this earlier with mamba and it worked. I'm starting to experiment with mamba more and more, but still need to use regular conda in several important settings.

[isuruf]

I would argue that then mamba is not doing what it is supposed to be doing.

[jjhelmus]

The correct answer with --strict-channel-priority and defaults as the highest priority channel is unsat.

[jjhelmus]

With flexible channel priority (the default option) conda gives the following solution which is likely desired.:

~$ conda create -n test python=3.8.* pymysql=0.10.* --override-channels -c defaults -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/jhelmus/conda/envs/test

  added / updated specs:
    - pymysql=0.10
    - python=3.8

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    pymysql-0.10.0             |     pyh9f0ad1d_0          42 KB  conda-forge
    ------------------------------------------------------------
                                           Total:          42 KB

The following NEW packages will be INSTALLED:

  _libgcc_mutex      pkgs/main/linux-64::_libgcc_mutex-0.1-main
  ca-certificates    pkgs/main/linux-64::ca-certificates-2020.6.24-0
  ld_impl_linux-64   pkgs/main/linux-64::ld_impl_linux-64-2.33.1-h53a641e_7
  libedit            pkgs/main/linux-64::libedit-3.1.20191231-h14c3975_1
  libffi             pkgs/main/linux-64::libffi-3.3-he6710b0_2
  libgcc-ng          pkgs/main/linux-64::libgcc-ng-9.1.0-hdf63c60_0
  libstdcxx-ng       pkgs/main/linux-64::libstdcxx-ng-9.1.0-hdf63c60_0
  ncurses            pkgs/main/linux-64::ncurses-6.2-he6710b0_1
  openssl            pkgs/main/linux-64::openssl-1.1.1g-h7b6447c_0
  pymysql            conda-forge/noarch::pymysql-0.10.0-pyh9f0ad1d_0
  python             pkgs/main/linux-64::python-3.8.3-hcff3b4d_2
  readline           pkgs/main/linux-64::readline-8.0-h7b6447c_0
  sqlite             pkgs/main/linux-64::sqlite-3.32.3-h62c20be_0
  tk                 pkgs/main/linux-64::tk-8.6.10-hbc83047_0
  xz                 pkgs/main/linux-64::xz-5.2.5-h7b6447c_0
  zlib               pkgs/main/linux-64::zlib-1.2.11-h7b6447c_3

[synapticarbors]

As I mentioned over on gitter, I think I just misunderstood what --strict-channel-priorty or channel_priority: strict in the .condarc was actually doing. According to @jjhelmus, if pymysql exists in defaults (and it does), it forces conda to ignore the version on conda-forge. I had thought, since I was specifying a version that only existed on conda-forge that it would pull python 3.8 from defaults and then be able to pick up pymysql from conda-forge. This is clear from the documentation, which I obviously didn't fully digest:

With strict channel priority, packages in lower priority channels are not considered if a package with the same name appears in a higher priority channel.

Making the channel priority flexible solves the issue.