On Mon, Jul 16, 2018, 12:53 Ralf Gommers <ralf.gommers@gmail.com> wrote:

What advantages scikit-build (which glues CMake and setuptools
together) brings?

If I understand correctly, scikit-build doesn't use anything from setuptools - it just copied the setup.py user interface. That's still a significant mistake imho, it should have a saner UI (declarative). But that's still minor compared to the advantages it has.

For a bit of background here...

When you run 'pip install <whatever>', and pip can't find a wheel, then it automatically downloads the source release and then invokes setup.py, while making various undocumented assumptions about exactly how setup.py works. So alternative build systems actually *have* to provide some kind of awkward setup.py interface to keep 'pip install' working. This is a significant part of why so few people try to replace distutils. (I think.)

Beyond better builds and IDE support, also support for cross-compiling could be valuable.

Finally, on a bigger picture level - distutils is badly maintained and good patches can go unmerged, while numpy.distutils is a pain to maintain. An actively developed sane build tool will be valuable to both us and the wider ecosystem.

The way distutils plugin system works, almost any changes can break people, plus the biggest issues are with the fundamental architecture. So yeah, it's pretty much impossible to make distutils better.

Instead, the general goal of the packaging maintainers at this point is to get rid of distutils. The big thing that will enable this is PEP 517, which replaces setup.py with a much smaller and properly-specified interface for new build systems to implement. The hope is that if creating alternative build systems becomes an easy and supported thing to do, then better options will emerge, and we'll get out of this situation where there's one tool everyone has to use and which isn't really good for anyone.

Unfortunately, support for this hasn't quite landed in pip yet. But that's the direction that things are going.

-n