pf_moore
(Paul Moore)
August 22, 2019, 6:10am
42
It’s probably worth pointing out that the PyPA is a collection of projects , not of individuals 1 . So in one sense, the answer to @pitrou ’s question is “Be a maintainer of a PyPA project”. As the PyPA explicitly does not have control over member projects’ governance, the rules on who is a maintainer for a particular project are at the discretion of that project.
1 I refrain from commenting on whether that’s obvious to people outside of the PyPA, and I don’t want to get into a debate on whether that’s the way it “should be”…
1 Like
pradyunsg
(Pradyun Gedam)
August 22, 2019, 7:25am
43
Yep yep.
All of these details are things that benefit from a clear document to point to saying: “this is how PyPA works” .
And, that’s literally the PyPA governance discussion.
2 Likes
pf_moore
(Paul Moore)
August 22, 2019, 7:56am
44
Agreed, I just wanted to add some context for people not involved in / following that discussion.
2 Likes
pitrou
(Antoine Pitrou)
August 22, 2019, 8:54am
45
The question then becomes: what are the formal rules for a project to become a “PyPA” project?
1 Like
pf_moore
(Paul Moore)
August 22, 2019, 9:21am
46
As @pradyunsg said, that’s precisely the subject of the governance discussions.
1 Like
brylie
(Brylie Christopher Oxley)
August 26, 2019, 2:39pm
47
Not sure if this is off-topic, but there is an ongoing discussion about making improvements to Python packaging:
This is relevant as I’m starting to figure out how to improve pip’s build logic and, hopefully, eventually move it out. A big part of the puzzle, is figuring out how we’d handle build environments. I’m aware that tox tried to use pep517, and gave up on it. pip isn’t 100% using pep517 either.
I’m considering this thread a place for a broader discussion about how we want to go about designing/working on the build environments library that works for the use cases where building with PEP 517 occurs…
Perhaps that offers an opportunity to reduce some of the pain points related to this discussion?
pitrou
(Antoine Pitrou)
August 26, 2019, 6:05pm
48
Not sure why. Can you explain?
brylie
(Brylie Christopher Oxley)
August 27, 2019, 6:24am
49
I vaguely recall there being two main threads in this discussion:
ambiguity surrounding PYPA (authoratativeness, participation, process)
pain points in packaging, relating to specific use-cases
Would the build step, i.e. building wheels, factor in to those pain points?
pitrou
(Antoine Pitrou)
August 27, 2019, 8:29am
50
I don’t think it would, no.
aeros
(Kyle Stanley)
August 29, 2019, 7:14pm
51
brylie:
I vaguely recall there being two main threads in this discussion:
ambiguity surrounding PYPA (authoratativeness, participation, process)
pain points in packaging, relating to specific use-cases
Would the build step, i.e. building wheels, factor in to those pain points?
The general ambiguity with PyPA might be fairly relevant to this topic, but the technical components of packaging or building wheels wouldn’t be.
pradyunsg
(Pradyun Gedam)
September 4, 2019, 2:43pm
52
I’ve tried to codify how PyPA functions today, into a formal governance model, that the PyPA can look into formally adopting.
Other than the voting mechanics (which are borrowed from CPython’s governance model), that’s basically how the PyPA functions today AFAIK. Maybe that document addresses some of the concerns that @pitrou has?
1 Like
pradyunsg
(Pradyun Gedam)
November 6, 2019, 5:54pm
53
FYI - @dustin just filed a PR to adopt the aforementioned governance model to be adopted as a PEP – https://github.com/python/peps/pull/1221/ .