On Thu, Sep 5, 2013 at 8:33 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > 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.
Unfortunately there is not a malicious "modernized distutils" or "stdlib suitable replacement" vacuum; on the contrary great effort has been expended to that end. Distutils itself is not being removed or getting worse in an absolute sense and will continue to be about as suitable for packaging as it has been. A modern distutils is not required by but would be allowed by the cited plan. I will not do it because I have observed distutils2 but best of luck to someone else who may be willing and able to write the code. Distutils is un-maintainable not due to underspecification or unit tests but due to its basic design. Extensions have to reinitialize or muck about in each other's objects to work making it difficult to change either the interface or the implementation without breaking some of the hundreds of thousands of existing sdists. If you can produce the modernized distutils then you may. It would be an acceptable plugin in the eventual pluggable build systems scheme. Daniel _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
