[Distutils] Extracting distutils into setuptools

[Donald Stufft]

> On Sep 29, 2017, at 2:31 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 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.

I’m not sure that it’s going to be helpful to take distutils out of the standard library. It has many problems, and being in the standard library is one of them sure, but the more insidious problems are inherent in it’s entire design which we can’t really fix without breaking all of the things. The main blocker to improvement is primarily just that after two decades of existence tons of random setup.py scripts out there have reached in and messed with sometimes even super internal parts of distutils. 

There are bits of distutils that are super useful (Steve indicated the compiler support as one of them), and I think a better path forward is to do like we’ve done with the packaging library. Make a compiler package that can handle those bits and recommend that projects that want to handle compilation just reuse them (of course not mandate it!). Then we can focus first on creating a good API in that package without inheriting the problems of distutils, and then we can maybe work on bundling that inside of distutils and turn the distutils API into a shim over that (or just leaving it alone).

This leaves the question of what happens to setuptools since it is intimately tied to distutils. I don’t really have a good answer for that. Probably it’s best to keep setuptools moving along as it’s doing now without making major architectural changes to it. It inherited a lot of the problems of distutils where people reach in and muck around with it’s internals so it’s easy to break things if you make too many changes. 

Therefore we might be better to just mostly leave distutils/setuptools progressing as they are today and focus on a brighter future in the greenfield landscape of PEP 517.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170929/3261965c/attachment.html>