On 2024-10-04 12:16:57 +0100 (+0100), Stephen Finucane wrote: [...]
if the services were always updating their 'python_requires' to reflect the lower bound of our tested runtimes matrix then we wouldn't have an issue, right? [...]
I think it's orthogonal. Where problems mostly arise is when a dependency has increased its python_requires above the version of Python a CI job is set to use, but we attempt to apply a constraints file which insists on installing only the newer version even though that isn't suitable. Per my other reply, environment markers in the constraints file (or separate constraints files per interpreter minor version) would alleviate this. We experience the same exact problem with external dependencies, but when it comes to our own dependencies we've struggled to accept that we could deal with them in the same way. Less often, it's happening in integration test jobs where python_requires has been increased on a branch of some project and a test for another project wants to install the current state of that branch from source for an older interpreter, and yes coordinating the dropping of the affected jobs with a mass update to python_requires could help there, though we'd need better answers for how to deal with unresponsive reviewers in less-active projects (TC delegates someone to step in and approve those changes? ignore it and let those projects stay broken? mark the projects as officially inactive and drop them from the upcoming release?). -- Jeremy Stanley