[Distutils] Extracting distutils into setuptools

[xoviat]

I understand the motivation behind that PEP, but we're not really
deprecating distutils, just moving it out into setuptools. The goal should
be "not to break anyone's code."

2017-09-29 11:25 GMT-05:00 Brett Cannon <brett at python.org>:

> Actually, you can't remove any module in the stdlib that exists in both
> Python 2.7 and 3.5 until after Python 2.7 is no longer supported:
> https://www.python.org/dev/peps/pep-0004/#for-modules-
> existing-in-both-python-2-7-and-python-3-5 .
>
> On Thu, 28 Sep 2017 at 23:31 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170929/54fbad16/attachment-0001.html>