To be really clear -- conda build doesn't directly use ANY build/install system.

right -- conda-build simply runs the script it is told to run (by the recipe), and then looks and sees what files were installed.

In theory, one could build a conda package directly out of a binary wheel -- after all, as mentioned, they are actually pretty similar, but most folks would probably just use pip inside their conda-build recipe.

In fact, that is already being done -- most python packages are built with "setup.py install", but some are built by using pip to install a wheel.

But I didn't think that the goal of PEP 517 was to ensconce pip as the only way to install a package in Python.

So if a build system can install (like setuptools currently does), then conda recipes may well call it directly.

I don't think this really has any bearing on the the PEP, though -- As I understand it, the goal of the PEP is to formalize the interface between build systems and package managers -- and that can only be a good thing for other package managers.

NOTE: For the most part, folks want to use a pip-compatible install in conda-build, because users tend to also directly use pip to install stuff in conda environments e.g. if there is not a conda package available. If a conda package were built with, say, plain distutils, then pip won't find the meta data it's looking for, and might falsely see an unresolved dependency.

Personally, I've always avoided pip installing packages in conda -- preferring to make conda packages for all the deps I need, but conda-pip compatibility has come a long way, so it does work fine for many users.

But it would be nice if packages didn't NEED to be pip installed -- but I think that's an issue with the wheel spec (that may well be solved).

-CHB