Distutils has many problems as you said, but by direct implication, if setuptools is "intimately tied" to distutils, then setuptools has these problems as well (and I think that it does).
> 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. The answer (I think) is clear. Setuptools should take over the distutils namespace, even on older Python versions, and even when there is already a distutils in the standard library. If setuptools is imported first, then it can rewrite the import paths such that the setuptools version of distutils is used. This would extract and consolidate what has become a de-facto single project (distutils + setuptools) into one repository, reducing duplication of effort. 2017-09-29 15:06 GMT-05:00 Donald Stufft <don...@stufft.io>: > > > 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 > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
