I'm Cary Hawkins, and I'd like to serve on the Python Packaging Council. I help maintain Hatch, Hatchling, and PyApp. I came to this work because packaging is the first thing a new Python user touches and, too often, the first thing that turns them away — and I'd like more people to get to the part where Python is a joy to use. So the question underneath almost everything I do is a simple one: how do we make packaging better, and easier to actually do?
I believe the answer runs through interoperability. When Hatch, uv, pip, and the rest each solve the same problem their own way, the cost lands on users as confusion and on maintainers as drift. That's why I opened the pre-PEP to standardize the workspace table in pyproject.toml, so the monorepo model that Hatch and uv already ship converges instead of diverging. It's why I've been active in virtual-environment discovery (PEP 832) and the environment-discovery API, arguing for designs that serve remote environments and non-virtual managers like Conda rather than the merely expedient — and that don't put Python-based tooling at a performance disadvantage against faster newcomers. On wheel variants (PEP 825) I've pushed for a mandatory tooling contract around overrides, because a format pip, uv, and Hatch can't all honor fragments the ecosystem instead of serving it. Across all of these I try to keep the maintainer's chair at the table: what a spec actually costs to implement, and whether it's implementable at all.
I balance that with a firm commitment to securing the supply chain through packaging and PyPI — and I don't see those as competing aims. Better packaging is more secure packaging. I authored the pre-PEP for staged releases, which gives an index a bounded window to run security scanning before an artifact becomes installable, closing the gap between upload and exposure that today's model leaves wide open. I've also been prototyping a leaner, purpose-built archival format for distributions (SPAR) in the open, as a place to test what a more verifiable, better-structured artifact could look like. I put these out early and invite people to tear them apart, because the standards process works best when the hard questions get asked before anything ships.
If elected, I'd bring an active maintainer's perspective, a bias toward standards that reduce user friction, and a steady focus on making the ecosystem both easier to use and safer to depend on. And if you'd rather someone else in that seat — no hard feelings. This work continues either way, and I'll keep showing up for it.