---- On Wed, 02 Oct 2024 04:17:01 -0700  Stephen Finucane  wrote ---
 > On Tue, 2024-10-01 at 10:41 -0700, 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].
 > >
 > > 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.
 > >
 > > [1] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81d71/setup.cfg#L13
 > > [2] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c81d71/setup.cfg#L22-L27
 > >
 > > -gmann
 >
 > As has been said by other down thread, I think this is the wrong way to go.
 > python_requires delivers value for end-users and if we're failing to make use of
 > it then that's the real issue we need to address.
 >
 > Our deliverables can be broadly divided into services (a.k.a. "applications"),
 > libraries and clients (a.k.a. "libraries"). My understanding of dependency
 > management is that you want to be strict in what you accept w.r.t. Python and
 > dependency versions for an application (to keep the test matrix manageable), but
 > you need to be significantly looser when it comes to libraries (so that they
 > remain broadly useful). This is why things like Pipfile.lock files are
 > encouraged for applications but not for libraries. Put another way, there's
 > nothing wrong with saying we don't want to support installing Nova on e.g.
 > Ubuntu 22.04, but we probably don't want to artificially limit a client like OSC
 > or a library like debtcollector or stevedore in these environments. As I
 > understand it, the issue we had previously (and the reason we've since been
 > reluctant to bump 'python_requires') is that we've forgot/ignored this rule and
 > proceeded to make our *library* dependencies unnecessarily strict rather than
 > focusing first on the services.

I think Libs and client were my main concern over removing the 'python_requires'
as those caused the pain of breaking service testing. I am ok with this proposal if
we can remove this flag for our library and clients but keep it for services.