match with python active versions

[gpongelli]

An interesting match that can be added is also against active python's version.

E.g. everything is configured correctly with python 2.7 and 3.6 , but they're both at the end-of-life stage.

To let the user know about this state, I made a package times ago python-active-versions that could be integrated into this one to have a full picture.

What do you think ?

[mgedmin]

That is a nice idea! Something like

setup.py says:                    2.7, 3.7, 3.8, 3.9, 3.10, 3.11, PyPy, PyPy3
tox.ini says:                     2.7, 3.7, 3.8, 3.9, 3.10, 3.11, PyPy, PyPy3
.github/workflows/build.yml says: 2.7, 3.7, 3.8, 3.9, 3.10, 3.11, PyPy, PyPy3
appveyor.yml says:                2.7, 3.7, 3.8, 3.9, 3.10, 3.11

Warning: Python 2.7 is end of life since 2020-01-01.

There should be a way to turn that warning off, because some people intentionally keep support for older Python versions for various reasons.

I'm not sure if that warning should be shown by default, or if it should be opt-in.

The presence of the warning should not affect the exit code, i.e. it's not an error.

I don't like the idea of downloading information from the internet. I'm already committed to making new check-python-versions releases to keep up with new Python releases, so I don't mind manually updating an EOL date dictionary. I think.

Maybe the dates are unnecessary, and I just need a MIN_SUPPORTED_MINOR_FOR_MAJOR = { 1: None, 2: None, 3: 7 }.

[gpongelli]

There should be a way to turn that warning off, because some people intentionally keep support for older Python versions for various reasons.

Instead of a Warning message, that could harm people, just a message to let people know if selected versions are active or not.

I'm not sure if that warning should be shown by default, or if it should be opt-in.

you choose.

The presence of the warning should not affect the exit code, i.e. it's not an error.

Agree.

I don't like the idea of downloading information from the internet. I'm already committed to making new check-python-versions releases to keep up with new Python releases, so I don't mind manually updating an EOL date dictionary. I think.

I did choose to download data from internet to be more general as possible, without creating new package's release each time a python version goes to EOL or new one arrives. The only reason that led me to do a new python-active-versions release is if people changes the html webpage structure 😉
If you want, the package is there and can be added, then you choose the best way you prefer to include such data 😉