Hi 👋

My name's Axel, but people on DPO & GitHub know me as h-vetinari.

I've been working in Python Packaging for about 8 years, which was roughly the time I got involved with conda-forge. Many thousands of commits later, I've been around the block a few times, and have been part of the core team for a while. We serve >1 billion downloads a month across all major OSes and architectures, which is small compared to PyPI, but more than enough to have to stay on one's toes. 😅

Over the years, I've learned much more than I had originally bargained for about all build systems under the sun, the fractal creature that is ABI, as well as compilers, runtimes, linkers, symbols, etc. To misquote a famous trope: "9 out of 10 packagers agree, it's a miracle that anything works at all". One of my more memorable adventures in this respect (about SciPy vs. Fortran vs. Windows) has been documented here.

Ultimately, Python has remained my core language over all these years; it just so happens that I predominantly end up dealing with the most complicated cases of things happening under the hood of Python packages. To me, in important ways, Python has become a glue language that ties together very disparate languages and paradigms; only that the underlying complexity of all the things wrapped by Python doesn't go away on a packaging level.

Where I bring perhaps a different perspective is that, to me, all that is still just Python packaging. While I've invested an enormous amount of time into the conda ecosystem -- primarily due to being affected by the kind of problems it resolved more comprehensively than wheels -- I feel that the dichotomy between conda packages and wheels doesn't have to exist. Which is to say that IMO "native" Python packaging could become powerful enough to obviate (or greatly reduce) the need for the existence of conda packages in the first place, in a way that benefits everyone.

Many discussion threads (not least on DPO) show a clear picture that our users would like fewer tools and a more streamlined experience. At the same time, I believe the ability to innovate independently is an important aspect of the Python ecosystem. To me, this is a constant balancing act; we don't want either side of that divide to "win", as that leads to either stagnation or total chaos.

Rather, what I'd be advocating for if elected, is that we can continue to make progress through standardizing on well-designed and battle-tested concepts, while keeping a coherent UX story in mind, and at the same time encouraging innovation and then applying the lessons learned from that. In particular, I believe in our collective ability to evolve towards a better overall experience, rather than remain stuck in the status quo indefinitely. While it's imperative to provide a smooth and low-friction path for people to follow along with this process, I wouldn't shy away from investing some (carefully considered) breakage budget if the long-term payoff is worth it.

Finally, packaging is something fun and rewarding. If we can solve problems once, rather than have N users run into them and frantically search for solutions, that's a huge win. That also leads me to the final component that I consider a requirement for success: the individuals involved. In other words, I believe it's essential to encourage participation & help newcomers grow, but also know how to coordinate large-scale efforts and how to deal with the human side of things (mediation, conflict resolution, etc.). I have experience both in terms of coordination (e.g. the stdlib migration) and on the human side (championing several new members, building consensus and coordinating behind the scenes).

In short: after many years as a Python packaging citizen, I feel that there's a lot of things to improve, and perhaps even a realistic path to "heal" (or at least reduce) the divergence between wheels and conda packages. Either way, I'm passionate about improving the overall experience people get from interacting with Python. I'd be honoured to serve the wider Python community with the particular experience and point of view I can bring to the table.

Thanks for your consideration, Axel

Hi! I'm Pradyun (@pradyunsg). I've been an active contributor in the Python packaging community for nearly a decade -- most notably as a maintainer of pip, an active participant in the interoperability standards, a PyPI moderator, and as a co-organizer of every Python Packaging Summit so far.

I got involved in this community back in 2016, after engaging on a heavily-requested feature in pip. Since then, I've been lucky to collaborate with a lot of wonderful people in the community and made meaningful improvements to many packaging tools.

I like doing this work because getting something right in Python's packaging tooling can improve things for an enormous number of people -- and because doing it well requires learning about low-level details about how computers work as well as collaboration skills to help one work with the many stakeholders.

As a co-author of PEP 772, which established the Python Packaging Council (PPC), I played a role in setting the mandate and expectations of what the PPC will do. I'm putting forward my nomination because I want to help actually deliver on them by actively setting an early positive trajectory.

Experience

Over the years, I have been up to a lot in this space!

• Maintainer of pip, Flit, and many lower-level libraries that implement the standards (packaging, pyproject-hooks, installer).
• Editor of https://packaging.python.org.
• [Co-]Author of nine Python packaging PEPs.
• Co-chair of the Packaging Summits at PyCon US and EuroPython.
• Moderator on PyPI.
• Adviser to many Python package maintainers on packaging issues.
• Collaborator with Python redistributors to improve the Python experience.
• Helped establish governance structures for Python packaging as we outgrew our informal structures (including this election!).
• CPython Core Developer since 2021.
• PSF Fellow since 2019.

Focus areas

If elected, I'd focus on what I believe are the three most important things for the inaugural PPC:

1) Supporting Python packaging tools

By establishing clear processes around technical decision-making with existing contributors, helping improve the security posture of various projects, and through identifying funding opportunities with the PSF.

Supporting healthy maintenance of these projects is important because these serve as the foundations for the Python's package ecosystem. I expect that defining a clear relationship between the PPC and Python Packaging Authority (PyPA) projects will be an important piece of the puzzle here, since that relationship is not fully defined currently.

2) Improving Python packaging's user experience

Through improving communication with users, working to identify users' pain points, and working with the tool maintainers to address them.

I expect that part of improving the user experience will involve the PPC expanding the scope of what is considered "Python packaging" -- beyond the tools that are used to build, distribute and install wheels to the broader ecosystem of tools that are used to build, distribute, and install Python software. Strengthening partnerships with sibling communities will help us in this area.

3) Maintaining the interoperability of the Python packaging ecosystem

Through ensuring that the standards are clear and implemented correctly in the tools, improving the standardization process, and identifying areas where "tooling divergence" is preventing improvements.

The stewardship of the Python packaging's interoperability standards comes with this responsibility. It is important that the standards evolve as the needs of the ecosystem evolve, while also ensuring we're enabling the ecosystem to benefit from innovative approaches (as has happened through Poetry, Hatch, PDM, uv and other tools).

A lot of the PPC's work will involve collaborating with individuals and groups who will know a lot more than I do -- I don't think I have the answers for exactly how we'd do all of the above. What I do bring is a decade of doing this work in the open, a habit of listening, a commitment to putting the ecosystem and its users first, and a willingness to do the unglamorous work.

Having helped design it, I care a great deal about the PPC earning the community's trust -- I'd be honoured to help it do exactly that as a part of the inaugural council.

Thank you for reading!

I am a long-time open source maintainer and co-CEO at Quansight. Since 2010, I have served as a maintainer for NumPy and SciPy, acting as the primary lead on packaging and build infrastructure across those projects and the wider scientific Python ecosystem. I led the migration of NumPy and SciPy away from numpy.distutils to Meson and meson-python, and I am an active meson-python maintainer.

To address the complexity of native code packaging, I created pypackaging-native, which provides detailed problem statements on C/C++, Fortran, GPUs, and hardware dependencies. My involvement in Python packaging standardization dates back to 2012 across distutils-sig and Discourse, where I have continuously advocated for and reviewed standards that support complex and performance-critical workloads. Most recently, I became one of the drivers of the WheelNext initiative to address current wheel limitations, working on standards for wheel variants (PEP 817, PEP 825) and metadata for non-Python dependencies (PEP 725, PEP 804). I also package a number of projects in conda-forge and Spack, and I am deeply interested in improving how Python packaging and distribution packaging intersect.

On governance, I served on the NumFOCUS Board of Directors from 2012 to 2018. After years of volunteer maintenance alongside my work in industry as a physicist, I joined Quansight in 2019 to build Quansight Labs as a public benefit division and home for open source maintainers. Quansight has directed well over 100,000 maintainer hours into core open source projects, prominently including Python packaging tools and standards, as well as conda-forge.

If elected to the Steering Council, my priorities are threefold. First, to help establish the council on a transparent, predictable path while improving community review processes and decision-making workflows. Second, to improve support for native code, compiled dependencies, and hardware needs across scientific computing, ML/AI, and performance-critical workloads. Third, to strengthen the interaction with and support for distribution packaging, spanning Linux distributions, Conda, Spack, Nix, and beyond.

I am Saurav Singla, Head of Data Science and Market Innovation at the National Payments Corporation of India (NPCI). I am nominating myself for the inaugural Python Packaging Council to bring the perspective of a large-scale enterprise Python user, technical leader, researcher, educator, and open-source contributor.

Python is central to the development and deployment of modern data-science, machine-learning, graph-analytics, and fraud-intelligence systems. In enterprise and high-performance computing environments, packaging decisions directly affect reproducibility, security, dependency management, installation reliability, binary compatibility, accelerator support, and the ability to move solutions safely from research into production.

My experience includes leading AI and data-science initiatives, working with Python-based machine-learning and graph-computing ecosystems, contributing to open-source technical discussions, publishing applied AI research, and authoring Machine Learning for Finance. I have also taught and mentored learners in Python, data science, and machine learning.

I would bring an important downstream-user perspective to the Council, particularly from organisations that operate regulated, security-sensitive, and large-scale systems. I am interested in improving the packaging experience for data-science and AI users, including clearer standards, reproducible environments, dependable handling of compiled and accelerator-dependent packages, better interoperability between packaging tools, and more accessible guidance for users moving from notebooks and prototypes to production systems.

As this is the inaugural Council, its members will also need to establish transparent and inclusive operating practices and build effective relationships with PyPA projects, maintainers, the Python core team, the Steering Council, the PSF, and the wider community. I would approach this responsibility through consultation, evidence-based decision-making, constructive consensus-building, and a commitment to representing the broader Python community rather than any single employer, project, or tool.

I recognise that packaging is sustained by experienced maintainers and volunteers with deep technical knowledge. My objective would be to listen carefully, learn from those maintainers, contribute an enterprise and end-user perspective, and help turn community needs into practical, interoperable, and sustainable standards.

Affiliations: National Payments Corporation of India; Python Software Foundation member; author of Machine Learning for Finance; AI and data-science researcher; and open-source contributor. My candidacy is personal, and my views would not represent my employer.

I am a Research Software Engineer at Princeton University with a background in High Energy Physics. I have spent a lot of time focused on compiled code; I am a maintainer of pybind11, cibuildwheel, scikit-build, build, packaging, and other packages related to distributing and building Python projects. I've also been involved with teaching packaging: I wrote the current iteration of the packaging.python.org's guide on packaging a project based on PEP 621, and I am the lead author of the Scientific-Python Library Development Guide, and I have given various talks and courses over Python packaging, such as hosting the SIMPLE-Py workshop alongside SciPy 2026. I also wrote PEP 808 and implemented it across projects. I write about various topics including quite a bit on packaging on iscinumpy.dev, my blog.

I would work to be a fair representative for all users, but I have a strong connection and background with the scientific and compiled-extension community, which has a particular challenge set of issue and needs. I am interested in continuing to simplify the experience for developers shipping code (especially compiled code) and users seamlessly getting that code. I am also interested in improving and modernizing the standards around metadata, and supporting the needs of small and large projects alike.

I'm self-nominating for the inaugural Python Packaging Council. What I'd push for: aiming for good enough now and iterating on it rather than chasing perfection upstream, while not being afraid to say no, empathy for every use case, and compassion for the people doing the work.

A partial standard that lands this year and gets revisited or extended in two years beats a complete one still sitting in draft in 2030. A few review rounds are required, but I'd like to avoid stalling progress due to PEPs that spend forever in back-and-forth review chasing perfection from day one. I find it important to create extendable standards: start generic and high level, then optimize later by filling in the blanks. That doesn't mean saying yes to everything. Knowing when to say no matters just as much. This body has a veto and it'll need it, and a clear no is a service: it lets someone stop or come back with something better.

The first job is working out how this Council runs: how things reach us, how we take input, what we publish when we decide, how we hand over to whoever comes next. I want the rules we write to include the ecosystems that don't share our toolchain. Scientific and compiled builds, conda, distro packagers, mobile and embedded, internal mirrors. Each has constraints the others don't, and a process built around pure Python on PyPI keeps producing standards that fit none of them. They should be in the room while something gets designed, not handed a comment period once it's settled. And I want it democratic rather than convenient. Decisions in the open, positions on record, a way for anyone to put something in front of us without knowing one of us personally, and a written answer to who we report to and how we can be removed. We should aim to give anyone interested the opportunity to participate in the process.

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.

A bit about myself. I'm the primary maintainer of virtualenv, build, python-discovery, tox, pipx, filelock and platformdirs. I've been a PSF Fellow since 2021. I work at Bloomberg on the Developer Experience team, doing artifact repository hosting. That job pays for some of my open source time. I'm based in Los Angeles, USA. I wrote PEP 662, which was rejected in favour of PEP 660. I write at bernat.tech, including a recap of this year's Packaging Summit. PEP 662 is the bit worth knowing. I argued editable installs belonged in the frontend, a competing proposal put them in the backend, and 660 won. I'd still make the same case today. Having an answer mattered more than me being right.

I'd like to nominate myself to serve on the initial Packaging Council.

I am currently the PEP delegate for interoperability-related packaging standards, as well as a core Python developer and a pip maintainer. If you have been involved in any recent packaging PEP discussions, you will probably be aware of my views, and my approach - if elected, I plan on carrying that over into my role on the Packaging Council.

In particular, I feel that it is important for the new council to adopt a hands-on approach to standards discussions and proposals, actively working with PEP authors to help them to achieve the best possible outcome. Many of our standards are complex, and getting as much input as possible throughout their development is critical to achieving the best results. I do not believe the council should stay silent during PEP discussions, reserving their views for when they are asked to make a decision. Instead, they should be open about their priorities and views, and take the time to be involved in the whole process.

Having said that, I'm very aware that the current standards process - both the PEP process itself and the community discussion - can feel very confrontational, often acting as a deterrent for people who want to propose a standard. I think it's critical that the Packaging Council looks at ways to improve the process, making it more open, inclusive and welcoming. It's still important that we ensure that our standards are precise, robust and effective, but that can be done in ways that avoid authors feeling like their proposal is being blocked or criticised, and we need to make sure that happens.

I'd also like to see the Packaging Council take a wider view of what "packaging" involves. Historically, the community has mostly focused on projects that are intended to be built as wheels, for publication on an index like PyPI. I'd like to see us look at other ways in which people use Python, and how we can help them:

• People building and distributing standalone applications using Python.
• People working in more adhoc environments - scripting, or using tools like Jupyter.
• Distributors and repackagers

One of the big problems here (and indeed with anything around packaging) is collecting feedback from our users. There are significant portions of Python's user base who never interact with the packaging community, and who have no way of communicating what matters to them. I'd like to see the council look into ways of addressing that - it's a hard problem, but I think it's one we need to tackle, and the first step is acknowledging that it's something worth doing.

Finally, I'd like to say that I'm very proud of what the packaging community has achieved so far. If I look back to my early days with Python, before distutils/setuptools, PyPI and binary distributions via wheels, we have made huge advances in usability. It's hard to express how much of an impact that has had. But there are still significant challenges ahead of us. Python is being used in more and more diverse and specialised areas, and by more and more users who don't have a programming background. There's lots still to be done, but I'm confident that we can continue to improve the packaging experience for everyone.

Thanks for your consideration.

In 2012, the Python Packaging ecosystem had a divide when PyPA-based tooling and conda emerged to solve different problems. I am running for a seat on the council to help bridge the two ecosystems together to solve user pain points. I also want to help build governance that serves the council well for many years to come. I have a community focus and a diverse range of contributions that I'll use to strengthen the council while working as a team with the other members.

For the last year I have been on the conda-maintainers team while leading the conda OSS team at Anaconda as an Engineering Manager. I have been making technical contributions and helping to lead a team to deliver conda-pypi, a bridge from conda back to PyPI which allows conda to install wheels natively. This is a community-focused effort, and it is the type of bridge that I envision could bring the ecosystems together.

As part of this work, I have also been helping to strengthen the conda community and make it more vendor neutral. For example, earlier this year I helped work with the community and NumFOCUS to shift conda from an Anaconda-owned GitHub organization to a non-profit one. I also have been heavily involved with Conda Enhancement Proposals over the last year. I authored the draft standard for the wheels integration work described above. I have also reviewed and provided feedback on the broader set of foundational standards approved this year, including conditionals and extras support and a new backwards-compatible repodata update strategy. I would take that same community focus and vendor neutrality while serving on the council. I will also recuse myself from any votes that present a direct conflict with my employer.

Packaging touches build systems, distribution channels, and installers, and I've worked across all of them including smaller contributions to:

1. PyPA tools such as pipx
2. Cross-platform app packaging such as PyInstaller and Briefcase
3. Build systems such as Meson
4. Distribution such as being a conda-forge recipe and Gvsbuild (GTK stack for Windows) maintainer, and creation of and contributions to Homebrew, Winget, Flatpak, and AppImage packages.

For the last 6 years, I've also been a Python community organizer by running and frequently presenting at Michigan Python.

Prior to Anaconda, I also spent the last two decades engineering software systems and leading teams in the automotive and military sectors.

As a member of the packaging council, I will be able to leverage this experience to serve the community by helping to build these bridges across our current ecosystems and create lasting governance so that packaging becomes one of Python's strengths.

The inaugural python packaging council is an excellent opportunity to resolve a longstanding lack of broad expertise in real world challenges for packaging. Historically speaking there have been at least two heavily underrepresented groups:

• Linux and BSD distros
• packages with system-integrated C extensions

I am well-positioned to represent their interests; as a member of Gentoo Python I am one of the people building a Linux distro, with a heavy focus on python software, and as a core developer of the Meson Build System I help design the build system used by python packages such as numpy, scipy, and pandas.

I'm also a past maintainer or current contributor to two different Linux package managers. Arch Linux's "pacman" and Gentoo's "portage".

Build and packaging systems are my passion. I would love to be able to contribute my experience to help guide the next stage in python packaging.

I have been a Python developer for 15 years. I maintain the Python Developer Tooling Handbook, a practical, free resource on packaging and other developer tools, and pythonplot.com, a Rosetta Stone for Python plotting. My day job is as an ML infrastructure engineer at Spotify. I have contributed to CPython, Pandas, and Conda.

In my work and public projects, my goal is to understand real user needs and provide practical solutions. I hope to bring that same user focus to the packaging council. PEP standards are what have enabled the ecosystem of packaging tools we now have, and the packaging council has a unique opportunity protect and strengthen them.

A specific priority I have is to bring clarity to the Python Packaging User Guide. While useful, it has fallen behind the recent developments in Python packaging and is constrained by being limited to PyPA members projects.

My career has been built by Python, and I look forward to this opportunity to give back and help ensure the long term success of this great language.

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.

Nomination for the Python Packaging Council

I am nominating myself for election to the Python Packaging Council.

Python packaging sits at the intersection of technical design, community governance, and the practical needs of an extraordinarily diverse ecosystem. I am running because I want us to become better at developing new ideas, adapting to emerging uses of Python, and recognizing the people whose expertise sustains packaging.

Why I Am Running

Giving new ideas room to grow

In 2024, I co-created WheelNext with a simple objective: to foster a community where people can build prototypes, nurture ideas, and work together in a positive and constructive environment.

discuss.python.org remains an important venue for formal community discussions. However, it does not always serve early-stage and exploratory work well. Discussions can become long, fragmented, and difficult to navigate. Ideas can encounter too much "stop energy" before they have had an opportunity to mature, demonstrate their value, or even become precise enough for productive debate.

WheelNext provides a complementary incubation space: somewhere an idea can be prototyped, challenged, refined, and strengthened before it has to stand in the arena of broader standardization and governance.

As a member of the Packaging Council, I would work to create better conditions for experimentation across the packaging community. I want us to develop faster feedback loops, provide clearer paths from prototypes to proposals, and make it easier for contributors to explore ambitious ideas.

Our processes should remain rigorous, but rigor should help good ideas become better, not prevent them from getting started.

Preparing packaging for scientific and hardware-accelerated computing

Python is extraordinarily flexible. It can be used in ways that many people would never have anticipated (e.g. JIT-compiling Python traces into entirely different execution domains). This adaptability is one of the language’s greatest strengths.

The other side of that success is that many use cases considered niche or highly specialized yesterday become mainstream requirements today. Python packaging must be able to evolve alongside them.

This is particularly important for scientific computing and hardware-accelerated computing. These communities are continuously expanding what Python can do, and their needs do not always fit comfortably within assumptions made by existing packaging standards, tools, and distribution models.

I want the Packaging Council to engage more closely with these communities, understand where the current ecosystem falls short, and support the experiments and initiatives needed to address those gaps. We should not wait until emerging use cases have become urgent, ecosystem-wide problems before responding to them.

Python has become a language of choice for science, engineering, data, and accelerated computing. Packaging must continue evolving if we want Python to remain a central and durable part of those domains.

Recognizing packaging as core Python expertise

I would also like to pursue a specific pathway for contributors to join the Python Core Team based on sustained contributions and leadership in Python packaging, rather than requiring a record focused primarily on contributions to CPython itself.

Packaging expertise is deep, specialized, and essential to Python’s success. The people who design packaging standards, maintain foundational infrastructure, shepherd interoperability work, and support the broader ecosystem possess vertical expertise that should be recognized within Python’s core governance structures.

Creating such a pathway would strengthen the relationship between packaging and core development. It would recognize the standing of experienced packaging contributors and, importantly, enable more of them to sponsor and shepherd packaging-focused PEPs.

This is not something the Packaging Council could establish unilaterally. It would require collaboration with the Core Team, the Steering Council, and the broader community. The Packaging Council can, however, clearly articulate the need, help develop credible criteria, and build the consensus required to make it possible.

Relevant Experience

Besides my founding role in WheelNext, my recent community work has focused on the relationship between packaging, core Python development, scientific computing, and the processes through which new ideas become standards.

I am an author of:

• PEP 817
• PEP 825

I have spoken about these broader challenges at PyCon US:

• PyCon US 2025, with Barry Warsaw: Reinventing the Wheel: A Community-Driven Roadmap for Python Packaging
• PyCon US 2026, in a panel co-organized with Michael Droettboom and Dawn Wages: Fostering Better Collaboration Between the Scientific Python Community and Core Python Development

I have also participated in Packaging Summits at:

• PyCon US 2025
• PyCon US 2026
• EuroPython 2026

Through WheelNext, the PEP process, conference discussions, and these summits, I have tried to help connect communities that often approach the same problems from different directions: packaging maintainers, standards authors, scientific Python contributors, hardware-accelerated computing projects, and core Python developers.

What I Would Bring to the Council

I would bring a bias toward experimentation, a concern for the health of our working environment, and a commitment to building stronger connections across the Python ecosystem.

I do not expect every experiment to succeed, and I am not running with a predetermined solution to every packaging problem. I want us to become better at finding promising ideas, testing them early, learning from failures, and helping successful prototypes develop into robust proposals.

I also want the newly elected Python Packaging Council to venture beyond the most visible or established packaging use cases. Python's future will be shaped partly by communities whose requirements currently appear unusual, specialized, or difficult to support. We should treat those communities as partners in the evolution of packaging rather than as exceptions to it.

Python packaging must support both what Python is today and what it can become tomorrow. That requires room for ideas to grow, sustained attention to emerging technical domains, and governance structures that recognize packaging expertise as core expertise.

I would be honored to work on those priorities as a member of the Python Packaging Council. Thank you for considering my nomination.

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!

I am self-nominating for the Python Packaging Council. I have used Python since 2013, mostly within the context of SageMath, the dominant and comprehensive open-source computer algebra system for research mathematics, which is based on Python and uses Cython to interface to a large number of specialized libraries. Since 2020 I have transformed the SageMath build system to use modern Python packaging practices (PEP 517/518 etc.). Since 2024 I have developed the fork passagemath, which provides the full functionality of SageMath in modularized form as over 120 source and binary distributions on PyPI. I also lead porting efforts to Windows and WebAssembly. As a member of the Python Packaging Council, I would like to contribute to resolving various long-standing issues: External dependencies of Python packages; the relation to the conda ecosystem; the practices of downstream distributors such as splitting PyPI packages into distribution subpackages.

Hello! My name is Lucas and I care deeply about the user experience of Python packaging. I am running for the Packaging Council as I would like to be able to work more effectively on some of the most pressing challenges in this space, and serve as a positive force enabling the hard work of others to come to fruition.

I love the shiny new tools we have available to us like uv and Pixi, and I strongly believe that pushing for the adoption of new tools and standards has the potential for massive improvements in contributor accessibility and inclusivity. I have witnessed these improvements intimately while introducing Pixi into SciPy.

I also believe that some of the hardest problems in the world of Python packaging are social problems, often related to disconnect between Python user-land and the work done by distributions to overcome difficult challenges. As a core maintainer of both SciPy and Pixi, I have focused on bridging the gap between these worlds and the communities which inhabit them.

I have substantial experience in the conda-forge ecosystem and believe that there is much to gain from bringing the worlds of PyPI and conda closer together, while learning new lessons from other distributions as well.

If elected, I plan to continue to act as a bridge between communities and focus on enabling problems to be solved via cross-ecosystem expertise. I would plan to treat meetings as a place to get things done and make meaningful progress on unblocking others, while remembering that clear communication and respect are perhaps the most important qualities to maintain while seeking consensus.

For some technical credentials: I am the driving force behind the CPython Pixi packages, which have been created with the goal of making downstream testing with instrumented builds of CPython accessible and reproducible. On the human side, I met many in the packaging community while speaking at the EuroPython Packaging Summit this year, and I know many others from the scientific / data science world from EuroSciPy.

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 in pyproject.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
• Being a PEP delegate for 5 packaging PEPs
  • PEP 639 -- Better license metadata in pyproject.toml
  • PEP 691 -- JSON API for package indexes
  • PEP 722 & PEP 723 -- inline script metadata
  • PEP 770 -- SBOMs

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.

My name is William Woodruff (@woodruffw on GitHub and DPO). I'm employed by OpenAI as a member of the Astral team; I currently focus on uv's security features.

I've been involved in Python (and Python packaging specifically) for about a decade; I'm currently a member of the PyPA, one of PyPI's maintainers, and an active contributor to Python packaging standards and modernization efforts. I've been privileged to be a core part of several large security and modernization efforts over the years, including building pip-audit, PyPI's implementations of MFA, API tokens, and Trusted Publishing, alongside PEP 740 (attestations), PEP 792 (project status markers), PEP 753 (project URL handling), and a handful of other things.

My interests in being on the Python Packaging Council are twofold:

• I want the PPC to be a truly normative body for Python packaging standards, i.e. I want its decisions to have binding force and not to be informal and limited in normative effect (like PyPA membership often is). PEP 772 defines this mandate, but the efficacy of the PPC in practice will depend in a large part on how proactive the inaugural council is willing to be.
• I want the PPC to have future-oriented, optimistic ideas about how to make Python packaging better. In other words I don't want it to take an incrementalist approach, particularly in its augural session.

In sum, I want the inaugural session of the PPC to establish a strong precedent for the PPC having both the political and technical authority to make large-scale changes to Python packaging.

My concrete platform:

• I will push for a modernization/overhaul of the Python packaging PEP process: a more streamlined and well-defined draft-to-PEP state machine, concrete assignments and timelines for responsible individuals, and an overhaul of the "living standard" process (which currently allows packaging.python.org to languish).
• I will push for the PPC to adopt a system of "good standing" for standard Python packaging tooling: Python packaging tooling that wishes to be considered "official" will need to remain in good standing, which will involve adopting relevant standards in a timely manner. This is a tall order, and will require us to carefully balance individual maintainers' interests and time commitments with the larger community's interests.
• I will advocate for the PPC to speedily approve and accelerate the adoption of a handful of next-generation standards, including:
  • PEP 694 (Upload 2.0)
  • Wheel variants/future wheelnext PEPs/JSON metadata
• I will advocate for the PPC to research and advance additional potential next-generation standards, including:
  • An improved archive format for Python packaging (replacing .tar.gz and/or .zip), as part of a larger effort to eliminate archive differentials and ambiguities by construction, instead of patching around them.
• I will advocate for the PPC to deprecate and remove legacy aspects of Python packaging, via the standards process. Some potential candidates:
  • Deprecating and eventually forbidding the upload of older metadata versions (and/or legacy individual metadata fields).
  • Deprecating "source archives" (versus sdists) as an installable artifact, as part of a larger initiative to improve the adoption of structured metadata in Python packaging processes.