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