[TIP] Is it kosher to subclass plugins?

[Fernando Perez]

On Sun, Jun 22, 2008 at 5:49 AM, jason pellerin <jpellerin at gmail.com> wrote:
> On Sat, Jun 21, 2008 at 4:32 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> So the plugin seems to be working (the doctest in question *is* run
>> correctly), but I'm wondering about that 'conflicting option' message.
>>  Am I misusing something?  I can provide my entire code if it will
>> help.
>
> When you subclass a plugin, you have to be sure *not* to re-register
> the superclass's commandline options. For example, you must override
> options() and must not call super(...).options(...) from your
> options(). You need to register only those options that are specific
> to your subclass; if none are, then your options() method should be a
> no-op. Likewise for configure() -- you don't want to call super()
> there either.
>
> Other things might go wrong, too -- this isn't a use case I planned
> for, unfortunately. So once the options/configure issues are worked
> out we may have some more pop up...

OK, thanks for your explanation.  Should I then understand that
plugins are never meant to be reused, and just copy the entire thing
wholesale, rename it and start from there?

Subclassing seems to run into these problems, though I actually
*wanted* to keep the same options, since all I was after was extending
the discovery algorithm but otherwise leaving the existing behavior
alone.  And there is no mechanism for customizing how the plugin
behaves, since it internally hardcodes the finder, doctestcase proxy,
etc (much like doctest itself hardcodes everything).

I'm just trying to understand what the best approach to properly reuse
code is in the long run, so please forgive me if I'm totally missing
the right picture here.  In the meantime I'll go for ugly wholesale
copy/paste, but that feels a bit unsatisfactory.

Cheers,

f