On Fri, Apr 17, 2009 at 1:54 PM, cdavid <da...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
