[Distutils] Comments on PEP 426

[Paul Moore]

On 4 September 2013 12:58, Nick Coghlan <ncoghlan at gmail.com> wrote:
> However, a more significant problem is that the whole idea is based on
> pure vapourware. That ideal "it's just like setuptools, but with a
> more elegant implementation that could be used to replace distutils in
> Python 3.4" library *doesn't exist*, and I have no desire to wait
> around in the (likely vain) hope of somebody stepping up to create it.

The problem with not even defining an interface is that there is no
upgrade path. Users use setuptools/pip or wait for the new solution.
Nobody can write their own replacement for setuptools (bento, for
example) and be sure it will integrate with pip.

It's a longer term issue for certain, but it *is* important. If we
don't get away from the implementation defining the behaviour, we'll
just perpetuate the problem of nobody being able to innovate because
everything needs to implement most of setuptools.

> Instead, I think the far more pragmatic option at this point is to
> just tell people "your setup.py must run correctly with setuptools
> imported in that process. If it doesn't, it is your setup.py is
> broken, not the build tool that imported setuptools, or setuptools
> itself for monkey-patching distutils".

The big question here, I suppose is do any such projects exist?
There's a lot of nervousness (I hesitate to use the term FUD) about
"how will projects that don't work with setuptools react?" but no
actual evidence of such projects existing. I believe that cx_Oracle
had an issue in the past. I must try to test that out again and report
it to them if so. Maybe MAL's projects are another potential test
case. And maybe numpy. It's hard to be sure, because projects in this
category are likely the more complex ones, and as a result are
probably also pretty hard to build (and consequently to test...)

Paul