[Distutils] Extracting distutils into setuptools

[Nick Coghlan]

On 29 September 2017 at 07:42, Matthias Klose <doko at ubuntu.com> wrote:
> On 27.09.2017 11:37, Nick Coghlan wrote:
>> On 27 September 2017 at 12:30, xoviat <xoviat at gmail.com> wrote:
>>>> In short, I think your proposal is a good one, but how can we allocate
>>>> manpower?
>>>
>>> (issue31595 on bugs.python.org)
>>>
>>> So what do others think of this? My sense of things is that people are open
>>> to the idea, but there isn't a plan to make it happen.
>>
>> As long as Jason is amenable to the idea on the setuptools side, and
>> pip's trick of injecting setuptools into a process to change the
>> behaviour of distutils imports continues to work, then this seems like
>> a reasonable idea to me.
>>
>> There will still be folks that want to patch distutils itself, but I
>> don't see that as being substantially different from folks still
>> patching the standard library Tcl/Tk bindings, even though there are a
>> number of popular non-stdlib GUI toolkits.
>
> In this case, we should deprecate distutils in python3.7 and remove it in 3.8.

Aye, that seems reasonable to me as well (especially if 3.7+ also
offers an "ensuresetuptools" module), and, looking at the recent(-ish)
commit history at
https://github.com/python/cpython/commits/master/Lib/distutils, I'd
suggest we ask Steve Dower if he'd be willing to be BDFL-Delegate for
the related PEP.

This is one of those changes where the longer term process improvement
benefits are already reasonably clear to the folks involved in
maintaining the software (i.e. we think it will provide a better end
user experience overall if distutils switches to being updated and
versioned based on the setuptools release cycle rather than the
reference interpreter & standard library one), so the main thing the
PEP process will need to ensure is that we're providing a sufficiently
non-disruptive transition plan for getting from the current state to
the more desirable state.

Between Steve ("Don't break Windows"), you ("Don't break Debian (et
al)"), me ("Don't break Fedora (et al)"), Donald ("Don't break pip"),
and Jason ("Don't break setuptools"/"Don't lumber setuptools with an
unreasonable ongoing maintenance burden"), along with everyone else on
distutils-sig, python-ideas, and python-dev, I think we'll be able to
make a reasonable assessment of what counts as "too disruptive".

Cheers,
Nick.

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