On Mon, Apr 20, 2009 at 4:36 PM, David Cournapeau <da...@ar.media.kyoto-u.ac.jp> wrote: > Tarek Ziadé wrote: >> >> no it doesn't. it's a generic tool to extend a command using plugins. >> > > OK. > >> >> Sorry, it's too easy to say "it sucks, scratch it and re-do it" ;) >> > > Yes, it is easy to say it sucks, but I am not saying that out of thin > air. Refactoring works if the general API is ok - but that's not the > case with distutils. As a data point, several people have tried to add > features to distutils in numpy extensions, and I went much further than > anyone else by bypassing distutils entirely, replacing the build_* > commands by scons. The core codebase is ten times smaller than the > original code it replaces (numpy.distutils is around 10 000 LOC, like > distutils itself). > > I agree that in the short term, distutils should be improved, but in the > long term, I don't see anything which would be both a significant > improvement while staying backward compatible with distutils, if only > because so many setup.py files depend on implementation details of > distutils.
In the short term, Distutils needs to be a better citizen when people wants to extend it, so they can do it without re-writing everything. You have this experience of "pain", share it through real use cases. In the long term Distutils needs to be *smaller* and to provide a playground for other tools. in particular for all the tools that need to build a binary package on a given platform. (We can't keep those platform specific tools in the scope of distutils) And the work done on various PEPs (all links at the top of http://wiki.python.org/moin/Distutils) are aiming to this goal. What about organizing a sprint soon btw, so we don't loose Pycon efforts ? -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
