Hi Nick (re-sending to the list)
On Sun, Sep 4, 2016 at 5:16 PM, Nick Coghlan
It's important to note that one of our key goals in PyPA is to get to a point where the API of a developer's publishing toolchain of choice only depends on the *version of the publishing tools* they're using, and not on the specific version of Python (as long as they're using a supported version). Encouraging the expansion and increased use of the distutils API runs counter to that goal in most cases (since it encourages writing publication and distribution code that will only work with newer versions of Python), but may sometimes make sense if it's info that really is CPython centric, or if it's a feature primarily aimed at tightly controlled environments that can aggressively drop support for older versions.
Today's state of things is that any project that is not a trivial pure-python module often has use of a combination of all three libraries: distutils, setuptools and pip in their setup.py and in a convoluted way. Newcomers to the toolchain look in similar projects for the right incantations that will fulfill their needs. We are pretty far from being in a state where good practices can even be defined. As a package author, I generally make sure that my need is not fulfilled by a proper usage of the standard library before adding a dependency to a third-party library, but packaging is an area where this does not work. Requiring pip only to know where distutils puts assets is pretty bad. Interestingly, on the subject of building extensions (where the has_flag method discussion applies), distutils.ccompiler is the only available tool and happens to not be monkey-patched by setuptools at the moment. Although setuptools re-defines buildext (and tries to get a version from cython first!) So it seems that there no real "right place" within setuptools to monkey-patch distutils' ccompiler. Sylvain