PPC nomination AMA for Bernat Gabor

Packaging PPC nominations
1

Hey folks, great to see so many great fellow maintainers and participants in the packaging ecosystem run for the packaging council. I’ve decided to run myself too. If you have any questions on my goals and hopes on what I’d fight for should I be elected feel free to ask me here. Thanks!

You can read my high level manifesto here.

For reference, I maintain the virtualenv, tox, pipx and build projects in the packaging ecosystem.

6 Likes
2
  1. How do you see the PPC’s role interacting with PyPI, given PyPI is operated by PSF staff, assisted by volunteers 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?
  2. 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?
3

As someone who often will be immediately impacted by the councils decisions, I think the PyPI (and by extension the PSF Infrastructure team) should get a permanent advisory role on the council. This would mean they would participate in meetings, even though they might not get a vote, and the council will look for them to guide on impact of adopted decisions, and feasibility of adopting some of those (both in general and timeline wise). I’d be open to 1 voting permanent member, though I’m unsure on that at this point. If neither of this is possible, we’ d still have to invite/consult the PyPI maintainers before we make decisions on topics impacting them.

This needs to be a constant conversation on each topic impacting the PyPI. The council obviously shouldn’t decide on topics where there’s no taste on PyPI side for good reason to adopt it.

PyPA as a GitHub org historically caused quite a few issues, so in the very long term I’d see it being dissolved. Its main draw always has been moving under it made the org feel more “official”. Instead, I think we can achieve the same if we have a python packaging page of council “approved” projects page on python.org, and maintainers of those projects to get PSF membership so they can vote for the council. Furthermore, I think we should have an official Q/A platform for communication between PSF (and with moderation, to the wider community) members interested in packaging to ensure council can keep communication with these members outside of election times. FWIW, this would mostly be a variant of what the CPython already does with their council.

That’s just some of the immediate ideas from the top of my head, but if someone has better ideas, I’m all open to hear more. Thanks for asking!

2 Likes
4

Empathy, because the scientist with a compiled dependency, the team behind a corporate proxy and the person shipping to a phone don’t want the same things, and a standard that looks obvious from inside one of those worlds is unworkable in another. Anything reaching us should say who it hurts as well as who it helps. Where that isn’t clear, helping the author go and find out is our job, not a mark against them. Compassion, because a lot of this is unpaid and the people doing it soak up the frustration of users who can’t see what they’re dealing with. Most of what we decide lands on someone who implements it in their evenings. Before we approve something we should know who that someone is and whether they’ve said yes.

I value this position in your nomination statement. How do you see the PPC acting with empathy and compassion for end users (especially those that are not computer scientists) and simplifying the complexity of packaging for end users who, as you state, have different needs?

5

I can see a few of these that could improve this situation in my humble opinion, just to name a few top ones:

  • peps: all PEPs should research on how the PEP will impact both our traditional user space but also scientific community directly too. Where PEP offers no direct support for the scientific stack it should at least allow extensibility for those ecosystems to build on top of it. Generally speaking I think PEPs while should ground themselves into primarily supporting the PyPI use case, they should provide interfaces that are open for extension.
  • documentation: open up https://packaging.python.org to contain more guidance on scientific user use cases, removing (some of) the need of external websites that achieve that. We still should/could link to some of these, but IMHO a user should be able to understand the core parts and basic building blocks for all packaging cases just by reading that page.
  • survey feedback: we already take yearly surveys in the Python ecosyste, which we could extend with additional questions and take those into consideration when making decisions. Furthermore, I think we should be more pro-active and this, and the council distill public feedback on various forums periodically (in the age of AI agents this is more achievable than was a year ago).
  • Error messages: I’d like the council to be able to focus on standardizing (or at least improve) these when emitted by the clients. Perhaps, with short what happened, and link to some centrally detailed longer variant.

Obviously happy to hear other peoples great suggestions too.

1 Like
6

I’m curious - when you say this, are you thinking specifically of conda-based ecosystems, or do you have others in mind?

Do you think that the PPC should give special consideration to conda over, for example, Linux distributions (which are also consumers of Python packages, with their own build and distribution processes)?

7

Primarily about scientific stack (that is conda and variants), but second yeah OS specific ecosystems.

8

Thank you for stepping up to serve on the PPC. You share an employer (Bloomberg) with another candidate. Do you see a conflict of interest if both are elected?

The PPC will take on an important large amount of work. How much weekly time can you commit to for the in-depth review of proposed PEPs that don’t touch your preferred interests?

9

When it comes to the conflict of interest, I don’t think there’s any here. On one hand, the bylines already outline that having two people from the same company is acceptable. On the second line, my company itself has no real stick in the Python packaging ecosystem besides being a user of it. We do not make any Python tooling ourselves, and our main business doesn’t require any of the upcoming proposals that are currently in the pipeline for the Python packaging ecosystem. I’ve been working at my company for 10 years, and even though I do have some heavy involvement in the ecosystem, I have never done anything for any of the projects I maintain or in general because the company asks for.

As for the commitment side of the thing, I already have an agreement with my company to spend some of my work hours on the Python packaging ecosystem. I’m willing to spend additional personal time to push things ahead. To put a number behind it, I’d be able to probably dedicate anywhere between 4 and 8 hours a week.

3 Likes