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
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
wrote: On 29 September 2017 at 07:42, Matthias Klose
wrote: On 27.09.2017 11:37, Nick Coghlan wrote:
On 27 September 2017 at 12:30, xoviat
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@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