The PY=36 tests failed with:

FileNotFoundError: [Errno 2] No such file or directory: '.nox/tests-iris-source/tmp/iris/requirements/ci/py36.yml'
nox > Session tests(iris='source') failed.

which doesn't make sense to me. I'm going to rerun them in case that magically fixes the problem

The PY=36 tests failed with...

Because SciTools/iris#4163 was merged yesterday

The PY=36 tests failed with...

Because SciTools/iris#4163 was merged yesterday

Thank you @trexfeathers !

I can't use the GitHub suggestion feature as it's not a file edited in this PR, but don't forget to update the project classifiers in setup.py for supported Python versions.

I can't use the GitHub suggestion feature as it's not a file edited in this PR, but don't forget to update the project classifiers in setup.py for supported Python versions.

Thank you @TomDufall ! I knew had missed something!

The py37 tests keep timing out as it fails to resolve the environment. I am looking into adding lockfiles such as was done in iris, and iris-esmf-regrid (SciTools/iris-esmf-regrid#68)

I have now added some of the lockfile infrastructure, using the implementation in Iris and iris-esmf-regrid as my guides.

I decided to mimic how we "bootstrapped" the use of lockfiles for the iris v3.0.x branch (see SciTools/iris#4154). I will extend this infrastructure to update the lockfiles (via a github action) in a later PR. For this we may have to consider running the update against all active branches (i.e. master, v0.1.7.x, etc). Note, for iris, only the lockfiles on the master branch updated.

Another thing to be aware of: as we are testing against both the master branch of iris and the latest release, this leads to complexity with the lockfiles. Options:

• Drop testing against the master branch
• Have two sets of lockfiles, one for when we test against the master branch, and one for when we test against the latest release
  In this PR I have just created lockfiles based of the latest release of iris (from conda_forge). It just so happens that this works for both since the requirements have not have diverged.

I have tried to do the minimum in this PR, so there will be some follow up work:

• Implement github action to update lockfiles
• doctests are broken. They haven't been running. Issue to address it: # 274
• coverage testing needs to be switched back on: Reenable code coverage testing #276

Thanks for reviewing @jamesp!

I'm happy for this to be merged.
Once this is in I will cut the 0.17.1 release

Another thing to be aware of: as we are testing against both the master branch of iris and the latest release, this leads to complexity with the lockfiles. Options:

Drop testing against the master branch
Have two sets of lockfiles, one for when we test against the master branch, and one for when we test against the latest release
In this PR I have just created lockfiles based of the latest release of iris (from conda_forge). It just so happens that this works for both since the requirements have not have diverged.

What are the benefits of testing against master/branch-a/branch-b vs. only testing against a released version? There is a lot of complexity added by doing so, we should be clear what we are trying to achieve by doing so.

An alternative may be to have an integration test in iris that runs on new PRs that confirms whether changes break the latest release of iris-grib.

What are the benefits of testing against master/branch-a/branch-b vs. only testing against a released version? There is a lot of complexity added by doing so, we should be clear what we are trying to achieve by doing so.

An alternative may be to have an integration test in iris that runs on new PRs that confirms whether changes break the latest release of iris-grib.

I believe the intention of adding testing against master was so we get a heads up of breaking changes, but this relies the changes to go into the iris-master branch and not a version branch (e.g. v3.0.x). I suppose we don't get much value from it, at least not worth the complexity introduced by supporting, and breaks things unintentionally (e.g. iris dropping py36 support meant we had to drop py36 support here just to get the ci working. We could handle this more sophisticatedly, but again: even more complexity!

I also don't think it's necessary to test against master for all new iris-grib PRs. Just seems like overkill!

I would be in support of finding an alternative solution. Will raise an issue to address this, and we can have further discussions there.

@lbdreyer thanks for raising an issue to track this, seems like the best way to keep in on our radar.