PEP 639, Round 2: Improving license clarity with better package metadata

Packaging Standards
21

Given the discussion here, to expedite the process and align the PEP more closely with the general consensus and the expectations in PEP 621 as people are requesting, I propose essentially doing what @pradyung and others have urged:

  • Remove the separate license-expression key
  • Make the flat string value of the license key map to the License-Expression metadata value, as reserved by PEP 621, and deprecate the table subkeys
  • Update the Converting legacy metadata guidance accordingly, to reflect that legacy license.text metadata cannot be automatically converted during build if it is specified statically in [project] and can be warned instead
  • Keep license-files as it is
  • Simplify and update the rest of the PEP accordingly

In addition, to reduce the total length of the PEP by over half, I propose:

  • Moving the user scenarios and rejected ideas (over 50% of the current body text) to the appendix
  • Once PEP 676 is implemented, moving all appendices except the basic example (over 2/3rds the total length of the PEP) to separate supplementary file(s) in the PEP-639 directory, linked from the PEP; this would make the PEP itself far more focused and manageable while still preserving those resources for posterity for those who need them
  • Merging python/peps#2155, which will reduce the rendered length by another five full pages by eliminating the redundant 100-link references section (which I already converted to inline links)
  • Eliding the PyPA glossary portions cited in the Terminology section and replacing them with links, and trying to hopefully move at least some of those terms of general interest that aren’t there already to the main PyPA glossary instead.
  • Further reducing verbosity and excessive verbiage through the rest of the PEP with the kind assistance of @pradyunsg
4 Likes