---- On Tue, 01 Oct 2024 11:06:12 -0700 Takashi Kajinami wrote ---
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.
Yeah, we should be cleaning up these as soon as we stop testing anything. When we add release notes about dropping any Python version testing and support, we can easily update the setup.cfg also for the classifier.
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.
We declare the Python min version bump for cycle testing runtime and each deliverables python classifier also get updated. I think that is enough information to anyone looking for what all python versions things are tested and what all are not guaranteed. My point is just to tell what we test instead of saying what we do not test. -gmann
[1] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81... [2] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81...
-gmann