On Wed, Nov 11, 2009 at 10:36 PM, Robert Kern <robert.k...@gmail.com> wrote: [..] > > It does feel something like that. The build system is just one of the > problems with distutils' internals, in my experience. You can think of the > rest of distutils as a little application framework for command line > utilities. I think this framework simply fails to provide in very > fundamental ways, like the "extend commands by subclassing" design pattern. > That choice makes it fundamentally difficult to combine extensions together. > I really don't see a way to evolve away from that (and believe me, over the > last decade, I've tried). You just need to redesign the internals if you > want to get away from that. You can't get from any point A to any point B by > evolving in small steps that are functional (not to mention backwards > compatible!) all the way through.
I am very surprised about this statement. What did you tried for the paste decade and failed to do ? I hear some complaints since a week, but beside's David examples I didn't read any other precise use cases. We're looking through the build_ext use case, and we are making some improvement on the other thread. So why not doing this in other issues ? Let's discuss your use case. And if it means adding new options to run arbitrary commands like post/pre hooks to a given command, to avoid subclassing an existing command, let's do it. And let's drop the backward compat issues in these discussions, so we don't burn out in details. Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
