Deprecate support for EOL Python versions on MacOS

[bryant-finney]

Summary

PR #79 introduces GitHub actions for performing CI/CD. The pipeline executes the test suite across all supported Python versions on multiple operating systems.

actions/runner-images#4060 updates the macOS-latest workflow to reference macOS-11 (from macOS-10.5); this is expected to remove support for Python versions 2.7, 3.5, and 3.6. Accordingly, the GitHub actions configuration must be updated to accommodate this change.

Definition of Done

• CI tests for macOS are skipped/allowed to fail/expected to fail for Python 2.7, 3.5, and 3.6 on macOS

[jshwi]

@bryant-finney
I've had a look at this. if/else in yaml is pretty clunky (for specifying OS), maybe these versions could be dropped for all OSs as 2.7 and 3.5 are no longer supported by Pip? Is MacOS prematurely dropping support for 3.6?

[bryant-finney]

@jshwi

I see here that the EOL for 3.6 is just a month away, so it seems like the timing is about right for macOS 11 dropping support.

Hmmm I know GitLab avoids the need for if/else logic by defining the matrix like this:

pytest:
  # ...
  parallel:
    matrix:
      - PY_MAJOR: 3
        PY_MINOR: [5, 6, 7, 8]
        OS: [macos-10.5, windows-latest, ubuntu-latest]
      - PY_MAJOR: 3
        PY_MINOR: [7, 8]
        OS: macos-latest

GitLab would generate 14 jobs from this definition (12 jobs from pytest.parallel.matrix[0], and 2 from pytest.parallel.matrix[1]).

Do you know if GitHub actions supports an equivalent syntax?

[jshwi]

Not sure, I might have a look. That looks like the cleanest and most logical solution. Better than what I was thinking, which was something like:

if: matrix.os == 'macOS-latest'
python-version: [3.7, 3.8]
if: matrix.os != 'macOS-latest'
python-version: [2.7, 3.5, 3.6, 3.7, 3.8]

[bryant-finney]

@jshwi this is interesting: I was under the impression that executing jobs with macos-latest currently resolved to macos-10.5 and is transitioning to resolving macos-11. However, this CI log indicates macos-11 is already being used. Which is especially interesting given that all of the deprecated python versions are still passing

[jshwi]

@bryant-finney Hm, this is what I gather from the build log. 2.7 was a miss for the cache, so I believe the python action downloaded it anyway. I suppose the safeness of the python action might not show an accurate representation for the average macos user... Regardless, seems the build still passes, but doubt that means much if users cannot find 2.7 in their own environment.

[bryant-finney]

@jshwi while working on #88, I bumped into 2.7-imposed requirements a couple of times. I'm also seeing other similar patterns for supporting 2.7 smattered throughout the repo. So I think it makes sense to prioritize dropping support for 2.7 on all platforms (not just MacOS); after the tests are removed from CI and tox, we should be able to start chipping away at those locations/patterns as time allows

[jshwi]

@bryant-finney Well there won't be any more security patches etc for 2.7, so phasing it out should certainly be on the roadmap. Possible to just announce a deprecation warning up until the next minor release of this package.

Would you know if removing 2.7 would be considered a breaking change (3.xx -> 4.x.x)?

[bryant-finney]

@jshwi I wouldn't think so. In an ideal world, nobody uses 2.7 anymore, so the change would not have any impact. In a real world, anyone who is still running 2.7 is unlikely to install updates/upgrades to dependencies (especially since pip no longer supports 2.7)