This might be probably something we should discuss at vPTG. On 10/2/24 02:41, Ghanshyam Mann wrote:
Hi All,
As you know, we have a flag 'python_requires' in setup.cfg which is pinned to the minimum python version supported[1]. Every time we upgrade our Python testing, we usually bump the minimum python version in setup.cfg and that prevents the project from being installed on lower Python versions. We do have list of tested and supported Python versions in setup.cfg classifier, which is good and enough information to tell what all Python versions are tested[2].
The sad fact is that classifiers are not updated timely and sometimes horribly outdated. If you look at setup.cfg in a few repos you may see some doesn't declare 3.11 support and a few other still declare 3.6 support. Unless we establish a coordinated way to update these fields timely, it eventually leaves confusions on users. What I've learned is that inactive projects with unmaintained CI may not maintain these fields, and I'm unsure "use more less strict fields" strategy really helps the maintenance.
Flag 'python_requires' creates an issue (which has happened many times in the past) when a dependency like oslo lib bumps the version, and it makes all projects testing old Python versions fail. I know we should remove the old Python versions tested from projects first, but somehow, we all are busy, and a coordinated effort is always missed.
I understand the explained pain, but what is the benefit of allowing projects to maintain CI with EOL python version ? Also, If the project is not capable to maintain their CI then it's apparently a sign that the project is inactive and I'm unsure how much tradeoff we should pay to maintain these. We recently started marking some projects actively and this doesn't sound aligned with that direction.
IMO, we should remove this flag as it creates more issues than benefits. opinion? It will also help to continue users to install things on old python versions if it is working for them.
My main concern here is that some of the internal/external repositories are actually removing compatibility with Python 3.8 in some repos and removing the flag may cause wired errors instead of explicit failure during installation.
[1] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81... [2] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81...
-gmann