Python-eccodes version numbering changed again, Travis is testing against an old version

[stephenworsley]

Python-eccodes previously changed their version numbering convention which resulted in #3593 being necessary in order to keep Travis using the latest version. Recently, python-eccodes has changed their version numbering convention again (see https://anaconda.org/conda-forge/python-eccodes/files) so that the changes made in #3593 are now causing Travis to not install the latest version. In order to pick up the latest version again, the changes made in #3593 should be reverted.

[pp-mo]

AFAICT the problem here is not that the numbering system has changed.
It is that they have provided 2 builds for the same "version" (2020.04.0) without incrementing the build number. Which is simply a thing you must never do in a conda channel !!

E.G. the file "linux-64/python-eccodes-2020.04.0-py36hda16e5c_0.tar.bz2" dates to 2020-05-04 @14:25
And its info/recipe/meta.yaml has

package:
    name: python-eccodes
    version: 2020.04.0
source:
    sha256: b2589c1850d0906d5b22bf699c0977736a704ee35799e4ea618e253332793ac4
    url: https://github.com/ecmwf/eccodes-python/archive/2020.04.0.tar.gz
build:
    number: '0'
    string: py36hda16e5c_0

The file "linux-64/python-eccodes-2020.04.0-py38h8790de6_0.tar.bz2" dates to 2020-05-04 @14:29
(5 minutes later !)
And it contains "conflicting" version info

package:
    name: python-eccodes
    version: 2020.04.0
source:
    sha256: b2589c1850d0906d5b22bf699c0977736a704ee35799e4ea618e253332793ac4
    url: https://github.com/ecmwf/eccodes-python/archive/2020.04.0.tar.gz
build:
    number: '0'
    string: py38h8790de6_0

[trexfeathers]

While the 2 identical builds is doubtless a very bad thing to do, we shouldn't be encountering this issue at all while Travis is still pinned to the following:

python-eccodes">=0.9.1, <2"

Version 2020 is most definitely >2!

[pp-mo]

Version 2020 is most definitely >2!

I don't really understand that aspect.
It also appears, from comparing the two meta.yaml files, that they are nailing tight many dependencies, so one of the above is fixed to python 3.6, and the other 3.8.

[pp-mo]

Ok, I suspect this could be "what I just said", and not the version spec in travis.yml.
The problem may be that .travis.yml doesn't integrate eccodes with the original environment resolution, but installs it in a secondary step.
So, I think the eccodes "meta.yaml" for the python 3.6 version now requires exactly "python=3.6.9",
whereas we are trying to install in the environment we just created, which has 3.6.10.
According to https://travis-ci.org/github/SciTools/iris/jobs/691806720

So it might be installing the earlier one because it has a looser Python version requirement ??
I'll just check that out ...

UPDATE: I think I'm all wrong about this.
will update later..

[pp-mo]

Update : removing the pin gives segfaults
Maybe we need to pause here, and schedule work to address it at a better time :-(

[pp-mo]

removing the pin gives segfaults

Until the next iris-grib, which will fix it : SciTools/iris-grib#208

[lbdreyer]

We no longer install eccodes into Travis, so this can be closed