> On Sep 29, 2017, at 2:31 AM, Nick Coghlan <ncogh...@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.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
