Hey all!
I am running for the packaging council to help serve you with a focus on:
You can read my full nomination here: Nominee for 2026 Python Packaging Council Election | Python.org
Feel free to AMA.
I’d love to hear your thoughts on what a bridge between conda and PyPA might look like. I know that some people see conda as a package manager like pip/uv, whereas others see the conda ecosystem as more like a Linux distribution. What’s your view on that? And do you see conda-managed packages following packaging standards more closely in the future?
Hey Paul,
When I refer to conda here I am talking about a bridge between the conda ecosystem and the PyPA ecosystem. However, conda is also a package manager, and it is one of the package managers in the conda ecosystem which also includes mamba and pixi.
Unfortunately, the two ecosystems divided when PyPA-based tooling and conda emerged to solve different problems. However, over time with the addition of wheels which enabled compiled binary dependencies, and with projects like WheelsNext, the two ecosystems now have a lot of overlap in user goals. You often now here folks pip or uv to install packages like numpy, even on Windows where that was historically difficult unless you brought your own compiler.
The conda ecosystem does have strengths though with compiled dependencies, treating each compiled dependency as a separate package is more scalable solution and it has more capabilities with variant selection for different hardware types.
The PyPA strengths are on Pure-Python packages, including the strong standards that have been created as a foundation. Package selection on PyPI of 610K+ Pure-Python wheels is amazing.
I would like to see us play to both of these ecosystem strengths to bring the ecosystems back together. For example, over the last year, I have been leading a project called conda-pypi with conda-maintainers team to allow conda to natively install pure-Python wheels from conda channels (with a selection of all the Pure-Python wheels on PyPI). This work was across the conda ecosystem to add features like conditionals and extras, and name mapping from PyPI to conda-forge names. I would really like to see us do similar work to build a bridge the other way so that pip/uv could install conda packages natively.
I have experience in both ecosystems, and I can help bring all the great energy from both sides together.
Hi Dan.
What are your thoughts on reducing the confusion between conda (the open source tool), Anaconda.org channel for packages (which is often referred to as conda), and conda-forge? I think that there is still quite a bit of confusion in the Packaging Ecosystem about these terms.
With the growth of data science, scientific python, and use of Python in HPC (high-performance computing), how do you envision the PPC making progress to improve the end user experience when using GPUs?
Hi Carol,
I agree that this confusion makes things difficult. Since the term conda is overloaded, we should move towards only using that for the OSS package manager. For example, Anaconda shouldn’t call their conda installer with packages from their main channel Miniconda. The conda community also has been talking about renaming to something without conda in the name. However, I think we are a bit stuck on what to name it (dang, naming is hard).
My focus for scientific computing will be on the most pragmatic way to get to a great end user experience for all users. No matter the package manager you choose, it should be seamless to mix Python and binary dependencies together and have it optimized for the exact hardware you have.
Since the conda ecosystem has been working on supporting these use cases longer, they are further ahead. Instead of creating something brand new, the standards the PPC helps create should allow the PyPA tools to have parity and then work as a team to continue to improve those standards from there. I mentioned in my previous post about building bridges, the PyPA tools can get parity quicker by us teaching them to install conda packages rather than inventing a brand new format.
We should also learn from all the great research that WheelsNext did. For example, conda is a hardware detection through virtual packages is already good, but adding a hardware detection plugin could allow even more precise capability detection.
So to me, there are two main aspects to such “bringing together” - social and technical.
On the technical side, do you imagine the conda standards around things like distribution file structure, channel APIs, environment identification, etc, being brought under the PPC? Do you see the PPC requiring[1] conda tools to follow PyPA specs, or PyPA tools to follow conda specs?
I’ll note that the PPC governance PEP talks only about “packaging standards” in general. Do you view conda’s standards as coming under that remit?
On the social side, Discourse is where the PyPA-focused packaging community hangs out. Do you anticipate that the PPC will encourage the conda-focused community to move there (or vice versa - that the PyPA community move to the current conda space), or that a new shared space for both communities is set up? Or do you expect the existing communities to remain as they are, and for the PPC to create some other means of sharing knowledge and experience? If so, do you have an idea what that would look like?
Do you see this as a replacement for the work that’s currently going on to allow the PyPA ecosystem to natively improve support for binaries (wheel variants, external dependencies, etc.) or simply as another alternative? How would you prioritise the two?
To the extent of their authority - see my next question ↩︎
Hi Paul,
If we consider the broadest definition of packaging, both the PyPA and conda ecosystems have millions of users. If the Python Packaging Council doesn’t have empathy for and represent all of those users, I think it would be a huge miss for Python.
For technical standards, if the Python Packaging Council is going to represent all packaging users, then broad standards that it creates need to be able to cover both PyPA and conda ecosystems. Instead of trying to shove the full Python ecosystem together to start with, we should divide the standards in two major categories:
To answer your question, then conda tools do not need to follow PyPA specs and the PyPA tools do not need to follow conda specs, except where a tool wants to claim cross-ecosystem interop, in which case it needs to meet a Boundary / Cross-Ecosystem standard.
As things get started, there will naturally be some asymmetry here. The Python Packaging Council will have authority over the Boundary and PyPA Internal standards, but it won’t have authority over CEPs and CFEPs. Over time, we can have discussions if the conda steering council and the conda-forge steering council want to also delegate some of their authority to the Python Packaging Council, however, I don’t think that is required to start with or necessary for success.
On the social side, there has already been in person events having broad packaging community attendance, for example at the PyCon US and EuroPython packaging summits. For online discussions, similar to the technical standards above, I don’t think we need to force the whole Python ecosystems together in one place. It is fine if Boundary and PyPA internal standards are discussed here on DPO, and internal CEP/CFEPs are discussed on Zulip. The Python Packaging Council should also hold office hours and seek input in all of those places and the PSF Discord to try to get the broadest input and reduce contentious discussion on DPO.
On the topic of wheel variants and improved binary support, I would prioritize bridging the conda ecosystem. The context is once again we have had the two separate PyPA and conda ecosystems, and then a couple of years ago, Anaconda damaged trust in the conda ecosystems through changes to their Terms of Service. I believe that this caused some of the companies using Python to feel like their corporate interests were at risk due to potential vendor lock-in. Some of these companies then helped fund the WheelNext effort through dedicating resources to it, hiring consulting companies to work on it, and even potentially paying tool vendors to develop solutions. For transparency, I work for Anaconda and both Anaconda and the conda ecosystem are WheelNext members, but I can’t take credit for the amazing work that has gone into the draft standards. Also where any of this touches Anaconda specifically rather than the conda ecosystem broadly, I’d of course recuse myself from any decisions. The acute risk of vendor lock-in has eased since Anaconda updated their Terms of Service to make it more clear and conda-forge has continued to act as a strong community alternative. However, there is still some perception of needing more independence.
The Python Packaging Council needs to understand these corporate interests, but also focus on finding the best solutions for the millions of users in the Python ecosystems. If the major problem with the conda ecosystem is perceived vendor lock-in from Anaconda, I rather we take on helping make the conda ecosystem even more independent. Then we can bring those binary capabilities to all Python users and continue to improve it. This will be a much faster path to providing solutions to users than spending years trying to extend the PyPA standards that are already very powerful for Pure-Python use cases. I also don’t think the effort on wheels variants is wasted, for example, we should improve the conda standards to improve hardware detection like I previously mentioned.
Hope you don’t mind me hopping in to your thread, Dan! Started writing this before your reply.
Yeah, that sounds right to me!
If ‘coming under the remit’ means the PPC being in charge or having authority over those standards, then no, see the above answer.
If, however, it means something like:
I think those all sound like avenues worth exploring!
I would not see this as a replacement — for projects living in a world which is mostly Python, with some binary-related problems sprinkled in, the work for improved support in the PyPA ecosystem is clearly valuable. Furthermore, some of that work, like that on wheel variant ordering priority, will be transferable to analogous problems in the conda world.
On the broader question of prioritisation, I think one path that would be mistaken would be building up large binary distributions in the PyPA world in isolation, duplicating much of the work and ongoing maintenance of conda-forge. Instead, work on enabling users to install both conda and PyPI dependencies seamlessly seems like the more important focus. As noted at Conda pypi - Pixi,
The holy grail of Pixi is to have a single solver that can handle both [the PyPI and conda ecosystems].
Right now, I strongly believe that Pixi provides the best UX for Python users navigating this space, so it would be helpful to have someone knowledgeable in Pixi when figuring out how to improve that UX further. At the same time, I would also be keen to work on avoiding vendor lock-in.
As mentioned in my thread, I think that the PPC prioritising work on external dependency specification and PURLs would be quite helpful towards this end.
Thanks for the reply. Speaking as a pip maintainer rather than a PPC candidate[1], I have some questions about this approach. I don’t have any real feel for how much work it would be for pip to be able to install from conda sources, but my gut instinct is “a lot”, and I fear we won’t have the maintainer resource to support that. However, we do have a significant part of our user base that wants to use scientific packages like numpy/scipy/pytorch. I’m very excited about the wheel variants proposal because it will drastically improve the UX for such users.
How do you think the PPC can ensure that we maintain parity for wheel-based tools like pip and uv in a world such as you describe? Or to put it another way, how do we avoid falling back into the position we used to be in, where important packages were only available to users who were comfortable with conda-based tools?
Speaking as a PPC candidate, I’m strongly in favour of closer collaboration with the conda ecosystem, but I think we should let the community decide over time how much technical integration is appropriate ↩︎
A question for everyone in this conversation. The PEP in its expectations, mandates, and responsibilities talks about packaging ecosystem and improving the experience for end users.
If we continue to keep discussing “pure Python” (pip) ecosystem and “conda” ecosystem, we run the risk of not meeting end users need of “I want to install my list of packages for my system”. An end user doesn’t want to start every project with the following decisions:
In other words, I really want, for the sake of the users, for the PPC to discuss packaging as one ecosystem instead of two ecosystems. What are your thoughts on this goal? How would you try to achieve this goal?
Personally, I view it as crucial that every user, no matter what tool they choose to use, has access to whatever package they want. I agree 100% that expecting a user to care about what “ecosystem” their tool is based in, or having to choose a tool based on the package they want, is unreasonable.
Where we are right now, that means ensuring that it’s as easy as possible for package developers to publish their projects for all tools, or ecosystems if you prefer. My focus would be on that - eliminating barriers that force a developer to pick one ecosystem over all others when distributing their project.
In the longer term, maybe there’s value in unification. It would certainly make life easier for package developers. And maybe there’s a future where “one tool to rule them all” will emerge. But there’s value in diversity as well, and I don’t think we should be trying to force a particular direction here. Tool UX preferences are highly personal, and we haven’t yet seen “one, obvious way to do things” (or at least, those of us who aren’t Dutch haven’t 
). The PPC needs to work to get as much information as possible from end users[1], and guide the tool and developer community to satisfy user needs, but I don’t think the PPC should make assumptions here - we represent the user community, we don’t make their decisions for them.
Honestly, I think that setting up an effective way of doing this may be the single most important task for the PPC ↩︎
Hey Paul,
I haven’t looked deeply at the pip codebase to analyze this, but I expect that it would be similar to what we just did for conda-pypi, but in the reverse direction. The work can be broadly categorized as mapping and new features.
It isn’t a small change, but a lot of the trickier things like the mapping are already solved problems and could become Boundary / Cross-ecosystem standards and official libraries.
Hi Carol,
I agree that focusing on the users is crucial. My priorities puts end users installing and using packages first, and building and uploading packages 2nd, but both are important. Neither group should have to know or care about these separate ecosystems.
My motivation for talking about the two ecosystems is because this is something the Python Packaging Council does need to care deeply about in order to bring the ecosystems back towards one. However, as a user, our goal should be that they can pick any tool and have access to all of Python packaging without having to know any of these details.
Edit: wanted to make it more clear that I think the PPC should prioritize end users.
An obvious question is why focus on the conda ecosystem? Should pip install packages from npm, homebrew, crates.io, Fedora, Debian or AUR? This feels like a lot of complexity when it would seem sensible to me to instead focus on ensuring Python packages have enough metadata such that you can just generate a conda/homebrew/rpm/deb package and use the existing tools?
Hi James,
Thanks for the question! The 2025 Python Developers Survey showed that Data Science is now 51% of Python usage and 58% use Windows. The 2025 Python Packaging Survey showed that about 30% of respondents use conda as one of their tools. Conda-forge alone has 1.76B Monthly downloads. Pixi usage has continued to grow substantially as well.
To answer your question, we need to meet the current Python users where they are and there are millions of Python users using the conda ecosystem right now.