That’s not really true, e.g. here.
It’s a chicken-and-egg problem in the sense that as long as pip / PyPA consider installing non-python dependencies out of scope, yet installing all possible binaries that python projects might bring along in scope[1], then it leaves basically zero room for conda to contribute, because that stance effectively defines the problems that conda is solving out of existence.
So the 100’000ft view is that, to find a common path (and have it be pertinent for conda people to contribute), pip has to either:
- expand its mandate to also cover non-python dependencies, effectively becoming a full-stack, cross-platform installer
- restrict its purview, and allow resp. rely on plugging in other tools to fill the required gaps in installing binaries
Finally, while I don’t speak for anyone but myself, I’m spending the lion’s share of my FOSS time curating conda-forge, and know that ecosystem (and many involved people) quite well. Feel free to tag me on DPO for anything conda[-forge]-related.
more in-depth discussion in the link above ↩︎