[Distutils] Making commands extensible by default

[Tarek Ziadé]

On Fri, Apr 17, 2009 at 1:54 PM, cdavid <david at ar.media.kyoto-u.ac.jp> wrote:
>
> 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,
>

ok great, thx. I have myself several use cases and I think I might
have a working solution on the paper
for the extension of existing commands.

a new kind of option you can use in any command, but wich is not a
simple type like a boolean
or a string.  It's a class that would works with plugins.

class MyCmd(Command):
    foo = ExtensibleOption('foo')

from there, the command would be able to ask in its code the option
some values, by
calling some plugins with a generic signature :

for plugin in self.foo._get_plugins():
    values = plugin(self.distribution, self)

It's up to the command to define its extension points, and document them.

I am doing this code in a code base for another project, when I have something
running I'll get back here with it as a support for my example.

++
Tarek

-- 
Tarek Ziadé | http://ziade.org