CI: Enable testing with multiple python versions

[Shwetha-Acharya]

This change ensures that we focus to stay compatible with three most recent python versions and helps in making the codebase more robust.

[Shwetha-Acharya]

CI run with the above code changes: https://github.com/Shwetha-Acharya/sit-test-cases/actions/runs/5712217288/job/15475273867

[spuiuk]

Hi Shweta,

Thanks for this commit. These CI checks are essentially for maintaining code quality and consistency and are run only when new code is being committed to the repository.
It may be my own inexperience with python but I don't really see the benefit of running it with multiple python versions. What benefit does this add?

[Shwetha-Acharya]

Hi Sachin,
We normally see that the python code that work smoothly on a particular python version may break on very next python version. Testing code against multiple supported python interpreter versions with CI can lead to early detection of such compatibility and version-specific issues.

For example, flake8 which is used in this CI can produce different results or behavior when used with different python versions.

[spuiuk]

The tools flake8, black and mypy are mostly run in the CI environment which we control. Since these are used to maintain code consistency, we need to run it consistently against the same version of python.

[spuiuk]

Hi Shwetha, I've asked @synarete to give his opinion on this case. He wrote the CI bits for the project and has more experience on it.

[synarete]

Looks fine. May save us in the future from potential edge-cases related to specific python version. Two minor comments:

1. Use lower-case tokens for git-commit topic (ci instead of CI)
2. Commit message body has short lines. You may use up to 72-chars per line. If using vim as your git-editor, add the following lines to .vimrc:

autocmd FileType gitcommit set colorcolumn=72
autocmd FileType gitcommit setlocal spell

[synarete]

LGTM

[anoopcs9]

/retest centos-ci/xfs

[phlogistonjohn]

Personally, I think the change is fine - but I would have approached it differently. I'm generally in favor of testing with multiple versions, because the language changes and what's on my desktop may differ from what platform(s) I am deploying on. However, I prefer to use the built in mechanisms of tox to do this, and then other jobs like formatting don't need to be run repeatedly, just the jobs that make more sense (unit tests, maybe mypy).
Usually I want to test the oldest python version I expect to deploy on, the newest, and the "default" python on my system.
Building it into tox also has the advantage of not needing to replicate the CI environment of github and is simple to run on my local machine.

For stuff like this I lean to accepting the change, because it mainly will only affect contributors to the project, not a wide variety of consumers - but also iterate on it afterwards to improve/refine it for the project's needs.

[spuiuk]

Why is the CI system still waiting on "Run python code checkers"? Just wondering if we are missing something else.

[phlogistonjohn]

This happens every time you change the structure of your CI jobs, anything defined as a required item in your branch protection rules it'll appear in the list, even if its not run. Since the patch adds a new matrix the job name is now Run python code checkers (3.9) (and so on). But github does a poor job of highlighting this.

[Shwetha-Acharya]

ead to early detection of such compatibility and version-specific issues.

@phlogistonjohn Thats a good idea!
I will add multiple python versions to envlist of tox as well. In that way not just the CI checkers, the tests are also compatible across the python versions.

But I am still not convinced why should we test with oldest python version as it will be towards EOL(https://devguide.python.org/versions/). Testing three most recent supported verisons still seem sensible to me

[phlogistonjohn]

But I am still not convinced why should we test with oldest python version as it will be towards EOL(https://devguide.python.org/versions/). Testing three most recent supported verisons still seem sensible to me

Sorry I didn't mean to imply the oldest python version suppted by the python core team. I meant the oldest python version you/we want to support. So, if for instance we wanted to target Centos/RHEL 8 we would want to test on python 3.6 as our oldest version. But if we only mean to support centos/RHEL 9 we would test on python 3.9... and so on.

[Shwetha-Acharya]

But I am still not convinced why should we test with oldest python version as it will be towards EOL(https://devguide.python.org/versions/). Testing three most recent supported verisons still seem sensible to me

Sorry I didn't mean to imply the oldest python version suppted by the python core team. I meant the oldest python version you/we want to support. So, if for instance we wanted to target Centos/RHEL 8 we would want to test on python 3.6 as our oldest version. But if we only mean to support centos/RHEL 9 we would test on python 3.9... and so on.

oh okay got it

[spuiuk]

ACK

[Shwetha-Acharya]

Looks like someone with write permission will have to enable 'Required' field for "python code checkers (3.9)", "python code checkers (3.10)" and "python code checkers (3.11)" and remove 'Required' field from "python code checkers"?
@anoopcs9 @spuiuk

[anoopcs9]

Looks like someone with write permission will have to enable 'Required' field for "python code checkers (3.9)", "python code checkers (3.10)" and "python code checkers (3.11)" and remove 'Required' field from "python code checkers"? @anoopcs9 @spuiuk

That's in my TODO list once the PR gets merged.