Qualifications
My name is Brett Cannon, and I am nominating myself for the Python packaging council. My qualifications for joining the council include:
- Being a Python core developer for over 23 years and the 12th most prolific contributor over Python's lifetime (since April 2003)
- Serving on the first 5 Python steering councils (2019 – 2023 councils; I chose not to run a sixth time)
- Co-maintaining the 'packaging' project for 7 years (since Aug 2019, and thus I'm a PyPA member)
- (Co-)author of 7 packaging PEPs (roughly 9% of all packaging PEPs, and roughly 5% of all PEPs regardless of type; 4th most prolific author under either classification)
- PEP 518 --
pyproject.toml - PEP 621 --
[project]table inpyproject.toml - PEP 650 -- Specifying Installer Requirements for Python Projects (withdrawn)
- PEP 665 -- Predecessor to PEP 751 (rejected)
- PEP 685 -- Comparison of extra names
- PEP 751 --
pylock.toml - PEP 794 -- Import name metadata
- PEP 518 --
- Being a PEP delegate for 5 packaging PEPs
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.