I've been involved in Python Packaging for almost 15 years. The first public message I can find of mine on one of Python's packaging channels dates back to January of 2012 and if my memory serves me correctly around Dec of 2011 I started working on "crate.io" (not be confused with crates.io) as an alternative to PyPI, and by May of 2012 I was contributing to pip.
In that time I've served the community and contributed in a number of ways:
- PyPI Administrator and core developer, including leading the rewrite of PyPI.
- A core developer for pip.
- A core developer for Python.
- Standing BDFL Delegate for PyPI PEPs.
- Initial author of twine.
- Initial author of the packaging library.
- Author of many PEPs (440, 503, 518, 527, 592, 629, 691 and more).
Throughout all of these roles I've had the incredible honor of helping to steer the direction of this massive ecosystem as it grew up over the last 15 years. There have been some mistakes along the way, but overall I think we as a community has done pretty well.
I've never been particularly comfortable shining a spotlight on myself and I've always preferred to focus on the work at hand, so rather than go on about my credentials and history, I'm going to talk about the future of packaging, the PPC, and the work to be done and how I'd approach it.
The inaugural council holds a particularly important role in defining how the council operates, what kind of a role it takes, and setting the tone for future councils. This moment will be an inflection point and will alter the path that packaging takes into the future, not unlike 15 odd years ago when we first started using the PEP process for packaging in earnest and created the PEP-Delegate system to handle that. Therefore to me, the single most important task of the new council, is positioning itself, and the community, to be able to handle the problems of the next 15 years, not just the problems that we face today.
In my opinion, the key to that is fixing the process by which changes are made. It's no secret that the PEP process has not scaled well to the challenges of 2026, much less the challenges of the next 15 years. This isn't a problem only for packaging, as it's something that is on the Steering Council's radar as well, so the PPC will need to work with the SC to try and improve that process or determine that the needs of Python and Packaging are too diverse and come up with our own process.
Whatever process we end up with, ultimately I think we need to end up in a place where making changes to the landscape is far more lightweight than it is now. The heavyweight process we have today is burning out people who care and scaring away potential new contributors and has created a culture where people try to work around the process rather than engage it.
I've long said that in packaging we need to design for decades, not months or years, because we rarely have a way to "take back" something once we've added it, so we have to be careful about what we add. I think that will likely always be true to some extent, but I think an important direction for the future is finding ways to make than less true. We need to make it easier to try something out and iterate on it over time, rather than having to define the complete and final solution up front, otherwise we're going to be stuck with having to be very conservative in what changes we allow.
Beyond setting the tone and defining how the PPC works, any iteration of the PPC will almost certainly have to decide on proposals (whether that's through the PEP process or not). The mental framework/things I think about that I personally use when thinking about proposals for the packaging space is roughly:
- Ignoring difficulties in implementation, getting agreement on something, security, etc, what do the end users actually want or expect to happen in this scenario?
- How does it help or hurt the practical security of the ecosystem? I use the word practical very intentionally, because I am not concerned with theoretical security, or in other words, a 9/10 security stance that is on by default with little to no end user effort is what matters to me over a 10/10 security stance that requires every end user to spend 15 minutes per package they want to install.
- How does it affect backwards and forwards compatibility? If it breaks those, what level of impact is it?
- How easily can we iterate and extend it into the future? Does it back us into any corners that are hard to get out of?
- How complex is the solution in the proposal?
- Is the problem that's being solved worth the added complexity?
- Is the solution really specific to a single use case, and if so is there a more general solution that would work without much additional complexity?
- Is the solution super generic and tries to cover many use cases, and if so is there a more specific solution that would work that can remove a lot of additional complexity?
- How does the solution "mesh" with the existing landscape? Does it feel like it belongs or does it feel like a weird wart?
- Is there a better solution? Do we have someone willing to champion and implement that better solution? If not, is this one good enough?
Either way, I look forward to seeing the next chapter of packaging, and I'm excited to help out in whatever way I can to continue to push the ecosystem forward!