On 10/2/24 08:39, Ghanshyam Mann wrote:
---- On Tue, 01 Oct 2024 11:09:18 -0700 Jeremy Stanley wrote ---
On 2024-10-01 10:41:57 -0700 (-0700), Ghanshyam Mann wrote:
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].
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.
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. [...]
The entire point of that value is that, if the software can't work on a particular older version of the CPython interpreter, pip will choose the most recent release of the package known to work on the user's interpreter. If we drop it, anyone using pip to install on older Python versions will end up installing the latest releases of our packages (assuming declared minimum versions of dependencies will work with that interpreter).
I think this should be ok as users know that they are using an older python version, and installing the latest OpenStack can cause some issues. We still explicitly declare the supported Python versions when testing runtime and package classifiers.
That's "theoretically" correct, but honestly speaking I doubt all people using pip for installation checks the relevant document to select the version they install and in most cases they just rely on resolver. It might be a small portion, but I'm sure that this does break some of the existing use pattern.
Increasing the value too early does cause problems for development of projects depending on that package, but removing it causes problems for users installing from PyPI. Can't we just do a better job of gauging when it's safe to increase the setting? -- Jeremy Stanley