PEP 771: Default Extras for Python Software Packages

[astrofrog]

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
  • Not needed
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
  • Discussion/review at Draft review for default extras PEP astrofrog/peps#1 and extensive preceding discussion at https://discuss.python.org/t/adding-a-default-extra-require-environment/4898/152
• Suggested sections included (unless not applicable)
  • Motivation
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

Question for PEP editors: there are some gaps in the PEP numbering, so is this the correct number to pick? I'm happy to update this if not.

---

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

[pradyunsg]

I confirm that I am sponsoring this PEP.

[warsaw]

Very nice PEP! LGTM in general although I have included some comments and suggestions.

[astrofrog]

@warsaw - thanks for the review! I've now pushed changes to address your comments.

[hugovk]

Thanks for writing this up! It sounds useful.

[astrofrog]

@warsaw - thank you for the review! I believe I have implemented all your comments.

In addition, I have pushed a change to the reference implementation section to update links there, as the work on this implementation is now fully functional.

[pfmoore]

A few small typos

[astrofrog]

@di @pfmoore - thanks for the comments! These should be fixed now :)

[astrofrog]

Following a suggestion by @pradyunsg, it might be easiest to no longer make any substantive updates to this PR, and instead publish it once/if the PEP editors feel it is ready. Once it is published, I will shortly after open a PR which makes some changes/additions based on the discussion in this thread:

https://discuss.python.org/t/pre-publish-pep-711-default-extras-for-python-software-packages/77892

It will then be easier to review these changes rather than having to re-read the whole PEP, which is getting long.

And once that follow-up PR is merged, we can open the main discussion thread for the PEP.

[astrofrog]

I have rebased due to a conflict in CODEOWNERS but have not made any changes since my last comment.

[hugovk]

Thanks for the update! Looks good editorially, let's merge later today if there's no last minute suggestions from others.

---

PS Generally we try and avoid force-pushing, it's easier to review what's changed with normal pushes, and everything will be squash-merged to a single commit at the end anyway.

Another tip: please avoid putting @usernames in commit messages, GitHub can be quite annoying and end up pinging several times from other forks :)

[astrofrog]

@hugovk oops, sorry about the force push, there was a conflict and I am used to rebasing in this case for other projects.

[hugovk]

Thank you!

Next, please post to discuss.python.org, then open a quick PR to put that URL in Discussions-To and Post-History.

[astrofrog]

@hugovk - thanks for merging! As mentioned in #4198 (comment) I'd like to make a follow-up PR with a few key changes based on the pre-publish discuss thread, and only once that is merged open the main discussion thread. Would that be ok? (I plan to open up the follow-up PR this evening or tomorrow morning)

[AA-Turner]

This seems fine, there's no rush to open the next Discussions-To thread -- perhaps you could include the updates to Post-History and Discussions-To in the follow-up PR you plan on opening (just before that one is merged)

A