(One thing I realized I didn’t make super clear in the nomination, even though I mentioned it: I’m one of uv’s maintainers, and I see my role on the PPC including representing uv’s development team and the interests of uv’s community as they intersect/align with Python packaging and modernization.)
Do you see uv trying to push more standard changes upstream in the future? From my POV the uv folks are very engaged in discussions but have historically been a bit quiet in doing PEPs – I know a lot of your PEP work was while at your previous employer – and such to make changes and prefer to work around issues within uv itself. Is there something you plan on doing as part of the PPC perhaps to make it easier for folks like your co-workers and other tool maintainers more comfortable in proposing changes?
Yes! I think we already do some of this, but not as much as we can . For example we’re currently involved in the WheelNext PEPs, and we’re going to keep pushing on some other PEPs (like the Simple Index errors one, and the various (pre-)PEPs around Upload 2.0/staged releases, etc. Those are specific examples but more generally I’d like to see us lean more heavily into the PEP process, which brings me to…
Yeah – one of the things I had in mind with the “modernization of the PEP process” point is that it’s currently somewhat difficult to get involved in the PEP process, especially for packaging PEPs. I’d really like to see (and would work on, if elected) the PPC address that.
I think the specifics of that will be subject to conversation and consensus, but some of the things I’d like to see include us streamlining the packaging PEP process a bit more, and allowing the council/PEP-delegate system to assign “responsible individuals” (or something similar) who can act as subject matter experts/keep PEP discussion from spiraling out as it often does now.
How do you see the PPC’s role interacting with PyPI, given PyPI is operated by PSF staff, assisted by volunteers (yourself being one of them!) rather than something the PPC directly governs? Or maybe you think it should? Where would you draw the line between packaging policy guidance and PyPI’s own operational decisions?
PEP 772 leaves ‘establishing the Packaging Council and PyPA relationship’ to the inaugural council, and PyPA itself has never had real authority. Concretely, what should PyPA become: stay as-is, get formalized with real membership/governance, narrow down to just a project home + fiscal sponsorship umbrella, or get absorbed into the PPC’s standards role entirely?
I would like to see the PPC formalize the relationship between PyPI and the current standards process. At the moment PyPI’s interaction with standards falls into one of three buckets:
Surfaces that are explicitly controlled by PEPs, e.g. the index API.
Surfaces that “should” be controlled by PEPs but aren’t for historical/legacy reasons, e.g. the upload API.
Surfaces that should not be controlled by PEPs, e.g. PyPI’s UI, its own PyPI-specific APIs, etc.
I think this division is essentially reasonable, but I think the PPC can make it more explicit. I also think the PPC should (related to my response to @brettcannon) should use a consultative system for PEPs that ensures that PyPI’s admins and maintainers have a voice when a change affects PyPI directly. I think this system should be stronger than the one we currently have, which is (more or less) “hope someone notices and reads the full thread on DPO”
This is probably my spiciest opinion .
The short version is that I think the PyPA’s half-authority role isn’t sustainable long term, and that (through good motivations!) the PyPA encourages the kind of “fix it with another layer of tooling” pattern that’s given Python packaging a bad reputation (one that’s IMO not fully deserved, but has legitimate grievances behind it).
I think the inaugural PPC should strive to formalize the PyPA’s membership and governance. In particular I think the PPC should investigate a “good standing” system for PyPA. I think the details of that should be subject to deliberation, but the short version is that I’d like to see a project’s membership in PyPA act as a strong signal that the project offers a compatible, standards-conforming approach to Python packaging, rather than the current signal (which is that the project is roughly packaging shaped and solved a problem for someone at some point).
(I should also be clear: I don’t have specific packages in mind for that. I just think it’s the kind of thing that the PPC should do, so that when people see that a thing is under the PyPA org they can feel confident that there’s a high quality floor.)
Do you see any room for the PPC to open up changes to happen in a different process than the PEP process? What would that look like to you to move certain changes outside of a full blown PEP process?
Yes! The way I see it is that most of the bones of the current PEP process are good, but there are procedural things that I think the PPC can change about it to make it smoother and more effective in a packaging context. I guess there’s a Ship of Theseus question of how much we can change it while still calling it a “PEP,” but my personal preference is that we start under the assumption that the process will still be roughly PEP shaped, but with changes to delegation/responsible individuals that better fit packaging’s needs.
One major weakness of the current (packaging-specific) PEP process is that the lifecycle is kind of messy: we write PEPs, assign them numbers, and then they become “living” standards on PyPA’s side. But in practice the “living” standard isn’t really living, since people link to the PEP instead and also most changes to the “living” standard also requires a full-blown PEP (with some exceptions for things like manylinux).
I think it’d like to see a lot of that state machine squished down. For example I think the PPC should be thinking about ways to eliminate the full PEP requirement when modifying “living” standards.
(There’s lots of nuance there IMO, since it’s not always clear whether something needs to be a full PEP or not. But I want the PPC to tackle that nuance.)
I have a few questions about the PPC and PyPA relationship.
How would you feel about breaking out standards for packaging into an org outside of PyPA? For example, PEPs, standards, and packaging guide could be part of the PPC org responsibility while the PyPA org can continue to host packaging related repos.
How would you envision the PPC communicating out and asking for feedback from the PyPA projects as well as projects (pixi, uv, conda, spack) that are not part of PyPA but important to segments of the Python community?
Let me pile on (politely) with a few more PyPA ↔ PC questions.
First of all, I actually agree that the current structure of PyPA is not particularly useful. It leaves a lot to be desired and doesn’t communicate anything of use to end-users (it does for maintainers, but we shouldn’t optimize for that). However, there is a lot of tricky questions here:
Assuming that PyPA membership is subject to oversight and approval by the PC, how is individual committer/triager membership handled? Will individual membership be subject to PC approval, too?
How expansive is the concept of “good standing” meant to be in your eyes? Starting with “does project X implement all of the relevant standards and is standards-conforming?” makes sense, but I can easily see this drifting over time. In particular, one common complaint among packaging users is that there are too many tools and it’s hard to know which one to pick.[1] Do you envision a future where the PC mandates that a project is removed from the PyPA (or “good standing” status for non-PyPA projects) because it’s redundant with existing tooling?[2][3]
Expanding on the previous point, what about non-PyPA projects? Even in a world where PyPA membership is reimagined and sends a stronger signal, I don’t imagine that uv, poetry, or pdm would be rushing to join this organisation. To be clear, I’m not involved with any of those projects, but reality is that many users use tools outside of the PyPA umbrella, so I’m unsure how “PyPA” is meant to convey anything to those users (or those on the fence).
Of course, all of these questions are subject to deliberation and most likely we’ll end up at some sort of compromise, but I’d like to know better where on the spectrum *you* stand (especially since you seem to be one of the most ambitious candidates ).
TIA!
Well, before uv ate my lunch and possibly everyone else’s lunch ↩︎
For example, there is a possible (far) future where pip gains enough equivalent functionality from pip-tools such that the latter would be largely redundant for common use-cases. ↩︎
The alternative is that the PC mandates that the two projects merge, although that seems politically difficult to enforce. ↩︎
I think I would be in favor of this, very broadly speaking. In general I’m pretty agnostic to the ultimate naming/layout of where things live; I think the most important things the PPC can accomplish in its inaugural session are streamlining the packaging standards process and fixing some of the gaps that have made it less effective in the past (in particular, things like the living standards languishing and the standards process as a whole not having a direct consultation element with affected projects).
I guess that’s a long way of saying that, if I were elected, I would likely support something like that. But I’m also broadly wary of introducing another layer of organization/administration that both the community and packaging maintainers will need to familiarize themselves with; I think that would need to be ironed out so that the PPC doesn’t become just another GitHub org
I really appreciate this question, thank you! I’ve been hinting at this with words like “consultation” but to be a lot more explicit: I envision an improved packaging standards process as having a state machine (much like the current PEP process does), but with an explicit state for consultation with affected parties.
In practice I think that means we’d want to lift a lot of the current standards discussion off of DPO and into a more structured (perhaps threaded) platform where we can clearly track what state a proposal is in, what concrete concerns have been registered, etc.
Part of that is going to entail new responsibilities, and I think the PPC will have to own a few of them too! For example I expect the PPC will need to maintain a list of projects/maintainers outside of the PyPA who may wish to consult, and may also have to solicit consultation publicly (e.g. on DPO) when it’s unclear whether existing parties are sufficient. I also think the current “PEP delegate” role will be responsible for ensuring that consulting parties actually do so in a timely manner, i.e. consulting parties can’t time out the process by ignoring the request (but should also be given ample time to respond in good faith).
(I say all of this, but pragmatically I don’t know if we’d accomplish all of it in an inaugural session. But it’s the kind of thing I’d want the PPC to be thinking about.)
I think I’d like to see this handled on a project basis: projects that are in good standing (which all projects will initially be) can manage their committer/triage/maintainer roles as they see fit. In other words, IMO the PPC should have no immediate role in the day-to-day reality of who maintains a given PyPA project.
I think two exceptions to that might apply, both of which currently already apply in a de facto sense (and in general, I’m a big fan of making bodies more accountable by turning de facto policies into de jure ones):
I think the PPC should, on an emergency basis, be allowed to suspend a maintainer’s access to one or more PyPA projects if there’s a reason to believe they’ve been hacked, have become malicious, etc. This is something the PyPA org admins can already do (and I hope they would, if it ever happens), and I’d like to make it something more official so it can be done in an accountable manner. The specific dimensions of that are something I’d like the PPC to debate, but at an absolute minimum I think it would require a public disclosure within some timeframe of the action, along with a public explanation of the reason.
I think the PPC should be allowed to apply organizational policies that maintainers are expected to follow. For example, if the PPC determines that all PyPA maintainers should adopt strong (hardware) MFA for their GitHub and PyPI accounts, I believe the PPC should also have the power to enforce that determination by suspending access to source control. Like (1) I think this is a serious power and therefore an absolute precondition would be for the PPC to have disclosure and accountability guardrails.
Thanks for asking this! I think my view of “good standing” is minimal at the moment: I don’t think the inaugural council should expand it to include blessing any specific PyPA project, if multiple projects in a specific area are equally conformant. This leaves the larger problem of “there’s too many things to choose from” unsolved directly.
I see this as a part of my response to @willingc: IMO the PPC should pursue “consultative” relationships, i.e. work with major projects in the ecosystem on an official basis to ensure they’re properly consulted on major standards initiatives. In my mind that includes uv, Poetry, PDM, as well as the Conda ecosystem, etc.
So does this mean that you expect there to still be a PEP delegate for packaging standards, rather than the PPC taking on that role?
Personally, I’d assumed that the PPC would be responsible for deciding on standards, and PPC members should be involved in guiding and directing standards discussions. Are you suggesting there would be an extra layer in there, consisting of a delegate for each proposal?
(I was hoping that the creation of the PPC meant I could stop being a PEP delegate, and share that role with the whole council )
Sorry, I probably shouldn’t mix the terms around. I meant that the PEP delegate role as it currently exists will cease to be, but I can see the PPC effectively appointing a “responsible individual” from the PPC itself. That responsible individual would be responsible for keeping the standard from going off the rails and ensuring that it ultimately reaches a state that the PPC as a whole can make decisions about.
(Maybe that responsible individual could also be appointed from outside the PPC, e.g. the PPC could pick someone with subject matter expertise to represent the PPC’s interests when nobody on the PPC has exact knowledge in a given area? I think that’s worth thinking about more, at the very least.)
Thanks, that makes sense. I tend to think of that as something we could use the PEP sponsor role for. In packaging, the sponsor tends at the moment to be little more than an advisor on process, but I think the PPC could reasonably expand and formalise the idea of “packaging sponsors” in the way you describe.
My personal belief is that all PPC members should be active in any standards discussion, but that actual management of the discussion is best handled separately. And there’s no reason to assume that PPC members would be the right people to be sponsors - it’s a rather different set of skills.
I agree! I think all PPC members should be actively engaged, but I think I’d also like to see the PPC delegate responsibilities to ensure that there’s always someone on top of each standard proposal. I think the exact scope of that role should be subject to deliberation, but at minimum I can imagine it being useful for each proposal to have a PPC member assigned to it who is responsible for bringing it up at meetings, ensuring that appropriate external parties are consulted, etc.
Your Nominee Statement is very intresting I really appreciate what you have already done in various places to make python packaging much more secure.
Your statement lists a number of deprecations / cleanups that you would like to persue that might be considered breaking. In general that makes sense, there are a lot of perculiar things to be found once you dig deeper. At the same time you mention adding a system of “good standing” for tooling. This sounds like it would put a lot of additional preassure on non-commercial tools like pip that (from an outsider looking in) already seem to have not enough ressoures.
Would this porposal in its totallity not strongly faviour commercial tooling like you employers? This might not be the intended outcome. Seing how there is not much funding going around for the community packaging tooling I wonder if these actions would create incentives that in the end strongly favour commercial tooling - making the communtiy reliant on the whims of the AI bubble not bursting.
The goal would be to make this permissive, almost to an extreme: I think “good standing” would need to be evaluated over years. I also think it would be inappropriate for the PPC to evaluate it in impossible circumstances: the point of the “consultative” system I proposed above is that we should stop writing PEPs without consulting the tool maintainers themselves, which happens a decent amount at the moment (I am guilty of this ).
In other words, the way I see it is that it’s a tradeoff: we should make the standards process more consultative, but the flip side of that is that the community deserves redress when a project that does engage in consultation doesn’t adopt agreed-upon standards over a very reasonable time period. In practice I suspect this basically won’t happen (since I think the community as a whole is good - and getting better - about not writing specs that are onerous or impossible to adopt).
I don’t think so, honestly – my experience from years of both paid and unpaid OSS work is that companies are uniformly worse at adopting and conforming to standards than motivated OSS maintainers are. I think uv is sort of an oddity in that regard, but for reasons that have everything to do with its maintainers (who care a great deal) and very little to do with the corporate structure behind it (which has changed significantly over the last 18 months, without affecting development).
(Finally, I feel confident in saying that the “worst case” for uv is not a failure mode for the community: people can and probably will fork uv if it becomes untenable to use directly, for whatever reason. But even if they don’t, I feel confident - as a long term packaging contributor - that uv’s most valuable contribution to packaging is that it’s changed perceptions/standards around tooling, not the code of uv itself.)
Thank you for the detailed response @woodruffw ! With the added detail the proposed system / change in the way packaging PEPs are worked on sound like a good idea.
I still hope someone with a better grasp on crypto than me adds attestation checks to pip, seems like that PEP was implemented on the server side only.
