RFE: Allow project maintainers to edit Requires-Python metadata directly

[ncoghlan]

(Broken out of the discussion at pypa/packaging.python.org#450)

While pip 9 correctly interprets data-requires-python link metadata in the PEP 503 download API, there are a few UX challenges in getting that metadata set correctly:

• if you forget to set it in the same release where you break compatibility, you either have to ask the PyPI admins to update the database directly, or else have to publish a new release with a higher version number that restores compatibility again, before attempting to drop support for older versions again
• if you only upload an sdist, then PyPI won't be able to automatically extract the metadata
• if you upload a wheel file after the sdist, then PyPI also won't automatically extract the metadata (although that seems more fixable than the sdist-only case)

It seems to me that allowing the Requires-Python metadata to be set directly by project maintainers through the web UI would be a good near-term mitigation for all of those UX problems.

[di]

There's a lot of discussion about this field over at #2170 as well.

[dstufft]

To be clear, I am like 90% sure that the second and third bullet points here are invalid (or could be better worded as a single one, "if you attempt to produce the sdist with an old version of setuptools or upload with an old version of twine".

I'm generally opposed to editing the metadata that allows diverging from what is different inside of the package (although technically right now there is nothing verifying that the two are the same). This is going to become a bigger deal when we start digging into things like TUF, since the ability to edit this would also mean that an attacker controlled PyPI could prevent someone from getting a newer version of the package.

I also think it's a very specific solution to an otherwise general problem (the general problem being that you've published something that is broken, but not so broken you want to completely remove it and break == pins because that would break even more people). I think a better solution to this problem is support for "Yanking" a file. Yanking is different than deleting because it doesn't actually remove the file, it simply flags it so that compliant installers will ignore it unless specifically asked for with ==. This would need worked into TUF so that you can't yank without attestation from the key of course.

[ncoghlan]

I'm going to close this, as @dstufft's right that my second and third arguments are wrong: the issue is that PyPI relies on the upload client to extract and supply the correct metadata, and that's only a valid assumption for recent versions of twine and setuptools. If you use distutils (or another naive client) to do the upload, it won't extract and supply the modern metadata correctly.

This means that for pypa/packaging.python.org#450 we can just make sure we include "Use a modern publishing tool that extracts the metadata correctly" as part of our guidance.

For retrofitting metadata updates for older releases, a mechanism for auditing and/or syncing the PyPI database against the contents of the uploaded artifacts (as per #474 (comment)) will be more useful than an arbitrary editing mechanism.