Ian Bicking wrote: > I don't think changing distutils to improve error output would be hard > at all. It looks like there's a line in distutils.core that catches > these exceptions (and doesn't look like it actually catches all > exceptions?), and that can just be fixed.
I agree this is one of the thing which can be improved without unintended consequences. > > Another topic that has come up: I do agree subclassing makes it really > hard to have multiple lines of development (specifically something > like Setuptools or Distribute, along with ad hoc development in > setup.py files). But I think that can be resolved. Perhaps, for > instance, Distribute can have implementations of commands like build, > that can easily be customized or extended without subclassing (e.g., > by pre-build or post-build functions). In numpy's case, we subclass the Distribution class mainly to add new data which are shared within commands (for example, to build pure C libraries made available to 3rd parties, or to keep track of the scons scripts). I have myself tried the pre/post hooks for commands (for numpy.distutils), but I did not go very far: the problem was almost always linked to commands which need to share knowledge from each other. OTOH, I tried this when I started pocking into numpy.distutils 2 years ago, maybe I could go further today. Some things are fixable in distutils: for example, to build things, you should be able to get rid of the imperative operations, and have instead of registry of extension -> action (ala scons/waf). This would make adding new tools (cython, assembly, etc...) easier, as you would add tools through a registry instead of overriding build_ext as currently done by e.g. numpy.distutils or cython.distutils. Doing so while keeping backward compatibility would be hard, though. > I'd really be shocked if a > rewrite of distutils was necessary, or even necessary to simplify > things. That's the opposite of my own experience. I think I have given several reasonable examples of shortcomings of distutils: I would be glad to hear that each of them has a simple solution which is backward-compatible in distutils. But another way to look at it is to ask: What is there in distutils that you would consider important to keep ? It is important that people who maintain packages do not have to rewrite their setup to a new hypothetical system: asking thousand of developers to rewrite their setup would be insane. But this can be done without being tied to distutils API. David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
