On Thu, Oct 3, 2024, at 12:43 PM, Pierre Riteau wrote:
On Wed, 2 Oct 2024 at 20:14, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
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.
Actually I think that it is particularly for clients that we should NOT drop python_requires.
End users may be using old distributions and following documentation that currently works, but relies on having python_requires for pip to do the right thing. Similarly, consider automation that is installing packages from PyPI. We don't want to break this – we've sometimes forgotten to bump python_requires in the past and it has been painful.
Agreed. The issues gmann is referring to have to do with situations where constraints and python_requires are out of sync. When that happens you get an unclear error message about no version available and a failure to install things even though you can clearly see that version is available. But we have to remember that constraints are largely an artifact of how we run our CI jobs, and we can address these issues there. Users in the real world won't have the necessary context to know what specific versions of things work with which specific versions of Python. We should continue to mark that with python_requires so that the tooling handles this automatically for them. Then we can figure out some way of avoiding conflicts between python_requires and constraints going forward. I think the proposals to phase things out in stages should work well at doing that.