PEP 691: Refactor based on Feedback

[dstufft]

• Reorganize the content so we introduce things in a more gradual approach, first pulling in versioning, then the JSON serialization, then our content types, then finally tying it all together with content negotiation.
• Expand a number of the sections with more detail.
• Add ?format=<content-type> as an optional, alternative mechanism to using HTTP's conneg.
• Explicitly mention that the decisions made here enable repositories to do an endpoint per content-type if they desire.
• Add a recommendations section, to guide implementors on the best "default" choices.
• Add FAQ entries for a number of questions:
  • Implications for static file servers
  • Does this mean that PyPI is dropping support for PEP 503.
  • Why TUF doesn't force us to have a single URL per TUF target.
  • Why we haven't added application/json in addition to text/html.
• Support the PEP 629 metadata inside of the JSON responses and provide an area for any future data of that nature.
  • This required moving the /simple/ response into a sub key rather than a top level dictionary.
• Add PyPI to the Appendix
• Rename the dist-info-metadata-available field to dist-info-metadata.
  • Recommend that hashes for dist-info-metadata are provided if possible.
• Change the semantics of dist-info-metadata and yanked slightly to make them match gpg-sig better and to make it easier to use them (remove the presence of the key being significant, make the value itself communicate all of the information).
• Update the PEP-Delegate to be @brettcannon.

[AA-Turner]

@dstufft please may you add the required copyright declaration? I believe Cam asked before - from an editorial perspective we require it, but can't propose it ourselves as we don't hold the copyright.

Thanks,
Adam

[dstufft]

Didn't notice it wasn't there, give me a minute.

[dstufft]

@AA-Turner #2593

[AA-Turner]

Thanks!

A