On Sun, 28 Aug 2016 23:36:43 +0100 Paul Moore <p.f.mo...@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.) Regards Antoine. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig