PEP 772: Packaging governance process

[pradyunsg]

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
• 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
• 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

---

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

[AA-Turner]

The process set out in this section seems very "heavy", for want of a better word. Could you add some text to Rejected Ideas for why a PEP 729-like approach wasn't adopted?

[warsaw]

Typing governance is somewhat more closely tied to Python-the-language evolution than Packaging governance. I think it generally makes more sense for the TC to serve under the authority of the SC, while the PC would be more of a co-equal governing body. Most packaging decisions don't directly affect the language, CPython implementation, or standard library, which (at least IMHO) is the main sphere of responsibility for the SC.

[zanieb]

Does this exclude members of for-profit organizations? If so, should that be mentioned in detail somewhere?

[willingc]

Good catch @zanieb. It should not exclude for-profit members working on an open source project IMHO.

[pradyunsg]

We should clear this up before the initial d.p.o thread.

I'll talk out-of-band with the co-authors and update this PEP when we have better language around this.

[hugovk]

About non-profits, I can see you may want to limit to, say, two DSF members, but I imagine it would be impractical and not your aim to limit to two PSF members 🙃

Perhaps mention if this doesn't apply to the PSF?

[willingc]

I would say on a council of 5 that 2 PSF employees would be a maximum on the council.

[willingc]

I would be explicit about PSF members vs. PSF employees since I would expect most candidates to be PSF members.

[warsaw]

PEP 13 says: "In order to avoid any appearance of conflict of interest, at most 2 members of the council can work for any single employer" so I don't think the same ambiguity exists for the SC.

[pradyunsg]

Yea, this bit here isn't derived from other governance documents... We should clear this up before the initial d.p.o thread.

I'll talk out-of-band with the co-authors and update this when we have an answer.

[warsaw]

I thought we would put this in PEP 8800 (or other 8X00 range) to rhyme with the Steering Council PEPs in the 8100s?

[willingc]

Overall, nice work on this PEP. I'm happy to see it moving forward. I've made some comments based on my governance experience. YMMV.

[willingc]

Suggested change

	While there is overlap between the PyPA, Packaging-WG as well as the Python
	core team, the Steering Council is not well-placed to make decisions over
	Python packaging matters directly. Packaging only tangentially intersects with
	Python language evolution, packaging requires specialised expertise and deep
	domain knowledge (much like typing or the C API), and there is a different
	cohort of potential electors for a Packaging Council than the Steering Council.
	While the work of the PyPA, Packaging-WG, and the Python
	core team overlaps, the Steering Council is not well-placed to make decisions over
	Python packaging matters directly. Packaging intersects tangentially with
	Python language evolution and requires specialised expertise and deep
	domain knowledge (much like typing or the C API). A
	cohort of potential electors for a Packaging Council could better serve the packaging ecosystem and its distinct needs more effectively than the CPython Steering Council.

[willingc]

I suggest that you order these points in priority of short term and long term efforts. Perhaps:

Suggested change

	* Improve Python packaging's user experience.
	* Maintain the quality and stability of the Python packaging standards.
	* Formalise and maintain the relationship with the core team as well as the
	PSF.
	* Establish appropriate decision-making processes.
	* Seek consensus among contributors before acting in a formal capacity.
	* Make contributing as accessible, inclusive, and sustainable as possible.
	* Maintain the quality and stability of the Python packaging standards.
	* Formalise and maintain the relationship with the core team as well as the
	PSF.
	* Establish appropriate decision-making processes.
	* Improve Python packaging's user experience.
	* Make contributing as accessible, inclusive, and sustainable as possible.
	* Strive to seek consensus among contributors before acting in a formal capacity.

[willingc]

The limit or goal of 7 seems a bit arbitrary.

[willingc]

Good catch @zanieb. It should not exclude for-profit members working on an open source project IMHO.

[willingc]

The list of individuals on pypa-committers should be added as an appendix to this PEP.

[pradyunsg]

Thanks for flagging this. It made me realise that the mailing list's membership isn't strictly accurate today, and this is a detail we should clean this up before the actual vote.

I've made a note of this on my end, as a thing to follow up on separately -- there might be a case for adding an open question entry for the specifics of how to determine who is "actually" supposed to be a part of pypa-committers.

[hugovk]

I thought we would put this in PEP 8800 (or other 8X00 range) to rhyme with the Steering Council PEPs in the 8100s?

Hmm, no objection, although this is replacing 609, and the other recent council/WG/board PEPs didn't go in 8xxx:

	PEP	Title	Authors
PA	609	Python Packaging Authority (PyPA) Governance	Dustin Ingram, Pradyun Gedam, Sumana Harihareswara
PA	729	Typing governance process	Jelle Zijlstra, Shantanu Jain
PA	731	C API Working Group Charter	Guido van Rossum, Petr Viktorin, Victor Stinner, Steve Dower, Irit Katriel
PA	732	The Python Documentation Editorial Board	Joanna Jablonski

https://peps.python.org/topic/governance/

[miketheman]

There's a part of me that wants the time machine to go back and make a very clear distinction between import packages and distribution packages.
Python's import package behavior is very much tied to the language's evolution, is it not?

Would it make sense to clarify the use of the term "packaging" early on to refer to distribution packaging in the context of this PEP to stave off further confusion?
Unless the intent is that the Packaging Council will actively work to evolve the Python language's changes to imports?

[warsaw]

There's a part of me that wants the time machine to go back and make a very clear distinction between import packages and distribution packages.

Yes, the term "package" is terribly overloaded, but that's not uncommon in computing jargon. 😞

Technically speaking (and I know y'all know this), the only difference between a module and a package to Python's import system is that packages are modules that have a __path__ attribute.

Would it make sense to clarify the use of the term "packaging" early on to refer to distribution packaging in the context of this PEP to stave off further confusion?

When in doubt, always add the adjective to disambiguate.

Python's import package behavior is very much tied to the language's evolution, is it not?

Absolutely.

Unless the intent is that the Packaging Council will actively work to evolve the Python language's changes to imports?

No, I think the PC won't directly evolve Python's import system, although I could imagine there might be some future distribution packaging proposal that would require an import system change to function. That would be a case where the PC and the SC work together to make such decisions, perhaps as two separate, related PEPs.

[miketheman]

Should the phrasing account for scheduled out of touch time periods? If someone is intentionally away for over a month and has notified the rest of the council, would this affect them?

Suggested change

	If a council member drops out of touch and cannot be contacted for a month or
	If a council member unexpectedly drops out of touch and cannot be contacted for a month or

I understand that this is based on PEP 13, but that's not a reason to not improve/clarify if possible - and then update PEP 13 as well.

[warsaw]

If someone is intentionally away for over a month and has notified the rest of the council, would this affect them?

I would think not, but hopefully the member and the council can work together to discuss whether an extended, but in-touch absence should necessitate a resignation, in the best interests of the community.

I understand that this is based on PEP 13, but that's not a reason to not improve/clarify if possible - and then update PEP 13 as well.

There's definitely a process for that, and there have been 3 amendments to date.

[pradyunsg]

I'm inclined to say that this isn't an editorial concern but a concern with the specifics of the proposal -- and that we should discuss any such specifics in the corresponding d.p.o. thread.

I've taken note of this FWIW, and will make sure to flag this in that discussion + discuss with the co-authors as well.

[warsaw]

There's a part of me that wants the time machine to go back and make a very clear distinction between import packages and distribution packages.

Yes, the term "package" is terribly overloaded, but that's not uncommon in computing jargon. 😞

Technically speaking (and I know y'all know this), the only difference between a module and a package to Python's import system is that packages are modules that have a __path__ attribute.

Would it make sense to clarify the use of the term "packaging" early on to refer to distribution packaging in the context of this PEP to stave off further confusion?

When in doubt, always add the adjective to disambiguate.

Python's import package behavior is very much tied to the language's evolution, is it not?

Absolutely.

Unless the intent is that the Packaging Council will actively work to evolve the Python language's changes to imports?

No, I think the PC won't directly evolve Python's import system, although I could imagine there might be some future distribution packaging proposal that would require an import system change to function. That would be a case where the PC and the SC work together to make such decisions, perhaps as two separate, related PEPs.

[warsaw]

If someone is intentionally away for over a month and has notified the rest of the council, would this affect them?

I would think not, but hopefully the member and the council can work together to discuss whether an extended, but in-touch absence should necessitate a resignation, in the best interests of the community.

I understand that this is based on PEP 13, but that's not a reason to not improve/clarify if possible - and then update PEP 13 as well.

There's definitely a process for that, and there have been 3 amendments to date.

[warsaw]

PEP 13 says: "In order to avoid any appearance of conflict of interest, at most 2 members of the council can work for any single employer" so I don't think the same ambiguity exists for the SC.

[warsaw]

The limit or goal of 7 seems a bit arbitrary.

It kinda is! Do you think there shouldn't be any limit or a different limit? I think the intent was so that no one org could overwhelm the pool of members.

[pradyunsg]

Thanks everyone for the reviews here!

Given that there's over a hundred comments on this PR already... I have a couple of "housekeeping"-style requests:

• I'd appreciate if we avoid extended discussion outside of inline review comments.
  • Replies outside of inline "review comments" are much easier to lose track of when the discussion gets really long with reviews from multiple individuals (which is what is going on here, right now).
  • I'm marking things as resolved to close out relevant subtopics in our discussions here.
• If I've marked one of your comments as resolved and haven't actually addressed it (and it wasn't a nit pick), please feel welcome mark it as unresolved and add a reply there!

There's still more stuff to be addressed from these reviews... I'll come around to those in my next burst of addressing review comments here (it's late today).