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 <br...@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 <ncogh...@gmail.com> wrote: > >> On 29 September 2017 at 07:42, Matthias Klose <d...@ubuntu.com> wrote: >> > On 27.09.2017 11:37, Nick Coghlan wrote: >> >> On 27 September 2017 at 12:30, xoviat <xov...@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 | ncogh...@gmail.com | Brisbane, Australia >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG@python.org >> https://mail.python.org/mailman/listinfo/distutils-sig >> > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
