Hi Tarek, Tarek Ziadé wrote:
== work in progress, ==
What we want to do here is being able to define subsets in run(), sharing the same options environment.
so basically, a rough, generic run() method could be:
def run(): for func in some_funcs: func(self, options)
What exactly is options here ? The class instance member user_options or something else (a dictionary of options common to each function, a bit like environment variables in scons or waf). A related problem, but maybe outside the scope of your proposal is dealing with communication between commands. I think the only way to do it at the moment is to attach those data to the Distribution instance - that's very fragile (if only because every new distutils-related tool has its own distribution class, so you have to special case for every one of them). For me, that's one of the main issue in distutils: extending distutils without breaking other tools (paver/setuptools). I think we should also working with precise examples/usecases right away - in my own experience at least, the difficulties with distutils are mostly implementation details. I will work on a few examples which I found quite painful to implement while working on the numpy build system and add them to the wiki, to help the discussion, cheers, David -- View this message in context: http://www.nabble.com/Making-commands-extensible-by-default-tp22978698p23096... Sent from the Python - distutils-sig mailing list archive at Nabble.com.