PEP 735: apply community feedback, including reversion of [project] table changes

[sirosen]

This PR applies several changes in response to community feedback and my having been convinced by these arguments that modifications to the [project] table are a mistake within the scope of this PEP.

The commits here each addresses a separate piece of feedback:

• Remove [project] changes from Dependency Groups.
  This is the largest change, removing text about changing the [project] table and making several adjustments for correctness in response to this.

• Typing fix to PEP 735 reference implementation

• PEP735: Add clarification on 'requirements.in'
  This adds a small blurb to "How to Teach This" on requirements.txt vs requirements.in.¹

• More strongly discourage overlapping extras
  This changes a SHOULD NOT to a MAY, thereby widening the PEP's allowance for tools to reject extras which conflict with dependency groups significantly.

• Add PEP 735 note on direct extras usage
  An element of the feedback received was that using [project.optional-dependencies] does not require that the project defines a package if the toolchain allows for this usage.²

• Add use-cases link to the motivation section
  More than one person found the Use Cases Appendix hard to find, so adding an extra link is hopefully benefiical.

There are two questions I have about whether or not to add text, noted in footnotes below.
In addition to basic copyediting, I'd appreciate any input on those two topic.
I'm still on the fence about those additions.

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

---

📚 Documentation preview 📚: https://pep-previews--3990.org.readthedocs.build/

Footnotes

1. I'm not really convinced we need this text, or that it belongs in the PEP. Maybe I should go back and remove it? ↩

2. I'm also unsure about this element. It's making an allowance for usages which more or less seem to directly subvert PEP 621. I'm considering going back and removing this as well. ↩

[sirosen]

I have pushed two updates here (in series) to remove the parts about which I was wavering. This PEP is already hugely long relative to the size of change it proposes, and IMO making it longer demands stronger justification than has been provided. Plus I got some of the details about uv wrong anyway, so pursuing concision will also help protect the accuracy of the text.

[zanieb]

For what it's worth, I think adding more top-level fields to the pyproject.toml allowing declaration of dependencies is a huge change. It's small in syntax, but large in meaning :)

[sirosen]

I've applied the suggested edits, and took @ncoghlan's suggestion from the discourse to use Deferred Ideas. (I hadn't seen that section before, so I didn't know it was an option.)