warehouse: Reject packages without a Requires-Python

I’m a bit worried that this proposal will result in projects setting over-strict constraints (requiring only what they test on and support, for example, when older versions may well still work on a “don’t come to us if something goes wrong” basis).

Well but if you are an advanced user and really want to get this package on an old Python version you probably can figure it out. Though if you are a new user and pip install foo and it does not work you at a loss. So I would see over-enforcing as better than being too lax.

And the all point of Python-Requires is also exactly for those old-python-users not to install a too-recent version of the package. Mostly I implemented it in Warehouse/PIP because IPython wanted to drop 2.x and couldn’t without breaking for old user. I would even expect the opposite of you, and have project to drop support ini CI, break on old python, and forget to update Python-Requires.

As far as I am aware, Python-Requires is essentially just another dependency that the resolver (new or old) has to deal with

I have not been part of some of the discussion about the resolver so pardon me if I’m mistaken. But, unlike the other dependencies, pip cannot change the current version of Python right ? Requiring Python-Requires may dramatically reduce the search space of the resolver as the Python version is not a variable. It would even be strange to me if the resolver even knows about Python-Requires, wouldn’t you just immediately filter out any package that is incompatible with the current Python and give the resulting set to the resolver ?

It seems that the other half of this issue is “how can we make sure users update setuptools/twine more often?” - which would help for more than just this case.

For example:

• making twine perform version checks periodically and output a warning if it or setuptools/wheel out of date
• actively working with CI providers to ensure the tooling they use is up to date (it looks like Travis’ PyPI deploy addon already self-updates, but there are likely other common workflows that don’t use it, as well as other providers)
• updating as many of the “how to publish your Python package” docs/guides to begin with a pip install -U ...
• (plus the idea of adding support for passing back a warning message on successful upload mentioned above, so at least new installs are more likely to stay up to date in the future)

Regarding users already on older broken versions - less disruptive options (vs brownouts/blocking) might be:

• displaying a banner on the package page or when the user logs in
• emailing the user after upload

my goal when I talk about this is to envision the world as it could be in the future.

Agreed. My point above (which I didn’t state well) was that Requires-Python metadata, while useful, can (in the most general sense) only be evaluated at the same time as the other dependency constraints on a package, after we’ve read the metadata. And making it mandatory doesn’t really change that code.

It’s true that on PyPI the Requires-Python data is available from the index, and so can reduce the search space - and this is great. But pip (and any other real-world Python resolver) has to handle other indexes, and even local directories containing distribution files. For those, there’s no saving and Requires-Python has to be processed in the constraint evaluation phase, not the file selection phase. So we do the check in both places - one for efficiency, the other for correctness.

Don’t get me wrong - I’m 100% in favour of better, more strictly enforced, and static metadata. I just don’t think having this piece will materially affect how we code the resolver in pip.