[Distutils] Comments on PEP 426

[Nick Coghlan]

On 4 September 2013 22:51, Paul Moore <p.f.moore at gmail.com> wrote:
> 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...)

If such projects publish wheel files (modulo us getting the Linux file
naming problem sorted), then the only people the build issues are
likely to hit are those that force builds from source (like
zc.buildout and Linux distributions). Even then, projects that
encounter problems are likely to be hard to build *anyway* (since
projects with simple build needs usually aren't so dependent on
specific distutils details that they conflict with setuptools), so I
think the risk of making things any worse is minimal.

"Just use setuptools" is far from a perfect solution, but it's a heck
of a lot better than leaving vanilla distutils projects in the dark
ages of Python 2.6.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia