4 min read Python

My nomination statement for the 2026 Python packaging council

I have decided to run for the inaugural/2026 Python packaging council (PPC). I will say I have the support of my employer (Microsoft) to do this, but they didn't ask me to and my usual thing that I would quit before I let any employer pressure me into doing anything I didn't agree with still stands.

I will admit that writing this was a little hard for me since it's for the entire PSF membership (compared to the SC which is only Python core developers), and so I had to assume someone had no idea who I was (where with the core devs I have been around for so long that at the core dev sprint last year I was the 4th longest-serving member in attendance). As well, I'm not good at humblebragging, so I had to think about what to say, and in a way that didn't dismiss what I've done like I typically do (as an example, I introduced myself at lunch at PyCon US once and someone at the table said, "we know who you are, Brett"; that was very flattering, humbling, and I still don't totally believe people who didn't just attend a talk I gave at that conference know who I am).

Anyway, here is a list of stuff I have done for Python packaging and some stuff I would like to see happen as I put in my self-nomination statement.

Qualifications

My qualifications for joining the council include:

More about me can be found on my blog, public notes, and GitHub profile.

Goals

Here are some high-level goals I have in mind for the PPC.

Setting up the inaugural PPC

Having served on the first 5 Python steering councils, I have a somewhat unique experience in knowing what can (not) end up working for councils such as the PPC. If I were to be elected, I would try to help my fellow PPC members learn from the SC's experience.

Developer experience

There are two groups of users of packaging: producers and consumers.

For the people producing packages, I would want to help make the experience better. That includes having clearer specs with less edge cases and any new specs that would help ease packaging up some code. And hopefully making the process around specs easy enough that people are willing to bring up instances of where something should be updated.

For consumers, I would also like to see the experience improve. For example, part of why uv is so fast is it doesn't strictly follow the current specs (while pip always tries to follow the spec accurately). In those cases where uv doesn't follow a spec but has found it to work out, I think we should evaluate if there's a change to be made so that pip can have an equivalent benefit.

A good example of this is that uv assumes all wheel files have the same metadata, while pip doesn't since the specs say the metadata can vary. If the specs could somehow be updated so you only had to check a single copy of release metadata, then pip doesn't have to check every wheel it considers when trying to determine what to install which takes time.

Secure supply chain

Unfortunately, there are bad people on the internet. And those bad people know there are a lot of Python developers, so they are trying to exploit Python projects for nefarious reasons. As such, I think we should do what we can to make things hard for these bad people while not adding a bunch of burden on those who are doing us all a service by sharing their code in the world (i.e. better security without sacrificing the developer experience).

There are two ways to thwart attackers: keep them out and prevent yourself from being exploited if there is vulnerable. One way to help keep attackers out is verifying files are legitimate. One possibility for this is to make getting reproducible builds easier, from source to wheel. This would require everything from code to help package up the bits in a reproducible way to metadata to be able to trace a wheel file back to its source code. This would let people be able to independently verify the files uploaded to PyPI were not tampered with between the source repository to uploading.

For preventing exploitation once some vulnerable code exists, one approach is software bills of material (SBOMs). If we could make it easy to have SBOMs for every step of the packaging process as well as for anything you install, it would make it easier to know when you may be running vulnerable code. This work was started with PEP 770 (which I was a PEP delegate on), but there are more opportunities to record more SBOMs (transparently) along more of the packaging process.

Share