[Distutils] What is the official position on distutils?

[Paul Moore]

On 30 August 2016 at 12:14, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 28 Aug 2016 23:36:43 +0100
> Paul Moore <p.f.moore at gmail.com> wrote:
>> * as a result, there would have to be an *extremely* compelling reason
>> to make a change in distutils rather than in setuptools - sufficient
>> to justify the additional risk, the extra developer effort needed, and
>> the fact that any such change is only going to benefit users of newer
>> versions of Python
>
> There is a problem with this: distutils and setuptools don't document
> or specify their internal APIs.  Yet if you want to do something
> advanced, you have to hook into the command classes and either call
> their APIs or extend them.
>
> Using distutils, this is already tedious, since you have to go read its
> source code and try to figure out what happens (it's rarely obvious).
>
> Using setuptools, this is even worse, though, because setuptools builds
> on top of distutils by modifying the command classes, and so you have
> to figure out the effect that monkeypatching has on the overall
> behaviour (in addition to figure out what happens in distutils).
>
>
> I don't know if that's bothersome enough to compound the fact that
> changes made in setuptools can benefit all Python versions, but I think
> it's useful to keep it in mind.
>
>
> (that lack of programmability is really distutils' failure, of course,
> and setuptools inherited that failure by inheriting distutils'
> architecture.)

>From what I know, anyone who is actually hacking into the internal
APIs to that level tends to use only distutils (probably because as
you say, setuptools is even worse) and therefore falls into my
category of "people affected by distutils changes who won't mind if a
change is made to setuptools". Admittedly, that's a self-perpetuating
situation...

The fact remains that (as far as it's possible to tell) very few
people do dive into distutils to that level. At least, not many people
seem to have problems caused by the current "leave distutils alone,
make changes in setuptools" approach. Ideally, someone would be
working on alternative solutions to break the remaining few's tight
dependency on distutils, but with the effort they have invested in it,
there doesn't seem to be much interest in re-engineering something
that works.

Paul