[Distutils] What is the official position on distutils?

Paul Moore p.f.moore at gmail.com
Tue Aug 30 09:44:10 EDT 2016


On 30 August 2016 at 13:38, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 30 Aug 2016 13:34:22 +0100
> Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> 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".
>
> Except when, as you point out, pip injects setuptools nilly-willy when
> running setup.py?

I'm confused. People who hack into distutils internals can't cope with
having setuptools injected (because their hacks conflict with
setuptools' hacks). That's my understanding of the situation, but it's
based mainly on what I've seen of people saying "Don't break my
APIs!!!" when distutils changes have been proposed in the past. The
projects involved are already outside of the current
pip/setuptools/wheel infrastructure (they have their own install
processes, they don't host on PyPI, they are not pip-installable or
whatever). So injecting setuptools isn't relevant, because they are
outside that particular ecosystem.

What I'm trying to say (badly, it seems - for which I apologise) is
that if we change setuptools, only people working in the current
ecosystem are affected, and those projects have typically been OK with
the level of change going on in setuptools. People outside of the
pip/setuptools ecosystem rely on distutils, and appear to be heavier
users of the internal distutils APIs. As a result they appear to be
typically much more conservative in their requirements (precisely
because they had to work with an undocumented internal API). So
there's a much higher barrier to changing distutils, and making
changes in setuptools instead is less likely to break existing
projects (at a cost of making such changes not accessible to
non-setuptools projects).

This is largely off-topic by now, though. I wasn't trying to derail
the discussion about policy on distutils, so I'll drop this subthread
now, with apologies to anyone who found it a distraction from the main
point.

Paul


More information about the Distutils-SIG mailing list