On Thu, Oct 22, 2015 at 5:04 PM, Thomas Güttler < guettl...@thomas-guettler.de> wrote:
> Am 21.10.2015 um 17:15 schrieb Antoine Pitrou: > > On Wed, 21 Oct 2015 17:05:29 +0200 > > Nick Coghlan <ncogh...@gmail.com> wrote: > >> On 21 October 2015 at 14:55, David Cournapeau <courn...@gmail.com> > wrote: > >>> > >>> On Wed, Oct 21, 2015 at 12:52 PM, Thomas Güttler > >>> <guettl...@thomas-guettler.de> wrote: > >>>> ok, at the moment setuptools uses distutils. > >>>> > >>>> Why not melt them together into **one** underwear-pants-module? > >>> > >>> > >>> What do you hope getting from that ? distutils is in the stdlib, so > cannot > >>> change easily, and even if putting setuptools in the stdlib were > possible, > >>> you would now need to handle different versions of setuptools for > different > >>> versions of python. > >> > >> It's more useful to go the other direction and vendor a modern version > >> of distutils inside setuptools: > > > > It seems it would only add a bit more craziness to the current > > landscape. What happens to projects which have a need to monkeypatch > > distutils? How does it interact with the vendored version? etc. > > What are the needs to monkeypatch distutils? > > That's the only way to extend distutils in a meaningful way, because of the broken command concept (e.g. the command dependency graph is defined inside the classes instead of being defined by an external scheduler). As anybody who has dealt with that codebase will tell you, It is impossible to fix distutils without breaking most non trivial uses of it. David
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
