On 31 Aug, 2013, at 17:56, Nick Coghlan <ncogh...@gmail.com> wrote: > > This perception is just wrong. Mac OS X is a mess due to clang vs gcc vs > homebrew vs macports vs Xcode, Windows is a mess due to mingw and cygwin and > platform SDKs and visual studio (Express or otherwise). Linux distros are > also ridiculous, with different gcc variants, library locations and various > other things, depending on flavour and version.
Don't forget fat binaries on OSX, those seem to cause problems as well for folks building extensions. > > distutils itself is nigh impossible to work on, since it is underspecified, > and the fact it was added to the standard two years before unittest still > shows in its test suite. (This lack of test coverage is also a large part of > the reason setuptools *isn't* quite a drop-in replacement). The lack of maintainability of distutils is partly due to underspecification, but that's just as true for setuptools. Looking in from the peanut gallery, the lack of forward movement for distutils is for a large part due to pushback at first because folks were scared to break existing code using distutils and later because it was deemed unacceptable to break setuptools. This seems to lead to the sad conclusion that there will be improved package installation and distribution through wheels, metadata 2.0 and related standards but that distutils won't get to play along even though plain distutils would work just fine for a very large subset of packages. Most of my own packages only use setuptools for its dependency resolution, and that's for the most part provided by pip in the future. That's not to say that distutils is perfect, far from it, but creating a new and improved build tool that's is capable of dealing with the complexities of compiler variations will be a large project in its own right even without migrating existing projects to it. Ronald _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
