PPC nomination AMA for Pradyun Gedam

Packaging PPC nominations
1

I’m a bit late to the party, in terms of creating this topic – thanks Brett for this idea! I’m very excited that we’re actually in the process of establishing the inaugural council. :smile:

I did self-nominate myself, and you can find my nomination statement here:

Please feel welcome to ask me anything! ^.^

14 Likes
2

Because you happen to be in the PyPA as well. What do you see as the role of the PPC for the PyPA? What do you think should change for the PyPA once the PPC has been elected? What should stay within the PyPA?

2 Likes
3

I kinda wanna combine these all into “What happens to the PyPA with a PPC in place?”. :sweat_smile:

What do you see as the role of the PPC for the PyPA?

  • In support of their responsibility for the specs, to work with various projects in the ecosystem on the standards – better processes, better compliance, and so on.
  • Serve as a clear point of contact for fundraising efforts (similar to the SC w.r.t the developer in residence for CPython) related to PyPA projects.
  • Serve as a point for raising technical and social concerns – including providing feedback gathered from users, working with maintainers to improve communication, etc.

I believe I managed to get all of these written into the PEP, some of it being the mandate for the PPC even. :slight_smile:

What do you think should change for the PyPA once the PPC has been elected? What should stay within the PyPA?

I don’t have a fully formed opinion on these currently. I do believe this will be an extended discussion when it happens and, in that discussion, I would want the PPC to weigh the opinions of the maintainers more strongly than the entire electorate here (since the maintainers will be affected more directly here).

Some changes are implied by the PEP: It explicitly moves the standards and packaging.python.org into the PPC’s mandate. Moving those out might make sense, depending on how the rest of the PyPA ↔ PPC relationship ends up being?

Beyond that, if I were to write my not-fully-formed opinion down… I currently lean toward restructuring the PyPA but not too drastically?

I want the PPC’s main “job” in the “PyPA ↔ PPC relationship” to be consensus building, communication, and final decision maker (similar to the SC) on aspects related to the projects – ideally, in that order of how often they do it. Having the PPC be able to say “let’s revert this change” and actually having the projects do it would be great – to be explicit, I don’t think the PPC needs formal powers to be able to do these things (hence the theme of trust in my nomination statement).

As a small procedural thing, I want to remove the need for PyPA projects to be under a specific GitHub organization – it’ll remove the need for a certain chores for the group, and also remove the need for explicit in-kind sponsorship of CI resources.

I think there’s also possibly some value in having more projects on “equal footing” in many packaging discussions, but I’m currently not familiar enough with how the conda/pixi/conda-forge ecosystem operates to know what might be viable on this! That might require some sort of restructuring of what the PyPA looks like – possibly explicitly focusing on projects (rather than individuals) for membership.

1 Like
4

Thank you for the numerous efforts you have lead and supported over the years! I think the Nomination Statements alone qualify you no questions asked.

As a pip maintainer: How do you see the PPC’s role in regards to such an important tool? Should the PPC set direct technical goals / decisions for pip or only work on the standards - keeping implementation details / decisions in the hands of the pip maintainers / PyPA?

1 Like
5

As a pip maintainer: How do you see the PPC’s role in regards to such an important tool?

Two things related to pip:

  1. It’s the default packaging tool, that ships with CPython. I’m expecting[1] deciding what packaging stuff is shipped with CPython is explicitly in-scope for the PPC.
  2. It is a PyPA project, and PyPA ↔ PPC relationship needs to be finalized still.

Should the PPC set direct technical goals / decisions for pip or only work on the standards - keeping implementation details / decisions in the hands of the pip maintainers / PyPA?

I think the council can only help setting the direction for a volunteer project, and it should do so after engaging with the relevant volunteers. :slight_smile:

I am optimistic that the PPC will be able to help tactically through fundraising (GitHub - psf/fundable-packaging-improvements: Packaging improvements that could be funded · GitHub revival for example – looks like GitHub has an outage right now, so that might not work) – some of which will directly touch pip.

I’d definitely do not want the PPC over-managing any individual project – that’s the wrong way for the council to be going about anything. On the other hand, supporting the projects so that they can communicate and coordinate the changes more clearly would be a very good thing IMO.

  1. Quoting the PEP: “An elected Packaging Council would have authority over the interoperability standards, would guide the packaging tooling provided with CPython, and have the mandate to coordinate Python packaging efforts.” ↩︎

2 Likes