[Distutils] Extracting distutils into setuptools

Brett Cannon brett at python.org
Fri Sep 29 12:25:43 EDT 2017


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170929/00fc8f5d/attachment.html>


More information about the Distutils-SIG mailing list