prevent double activation of the same functionality (component sub-classing)

[ThurnerRupert]

we activated trac tags including the wiki module. it was possible to activate the standard trac wiki module too. the effect was that in the timeline two "include wiki changes" appeared (see ​http://groups.google.com/group/trac-users/browse_thread/thread/bfdff087ad1eddf8). it would be great having some mechanism preventing such a behaviour.

[osimons]

Coding-wise this is actually a tall order as one module inherits from another - in some cases you want both, in other situations you don't. Sometimes you replace all behavior, sometimes you just duplicate and override… Detecting when to auto-disable is difficult bordering on impossible, and could give unexpected results the other way for anyone using inheritance and mixins for their own development.

Plugins that do depend on other modules being disabled, could in theory actually disable it themselves by providing an explicit Option that does this change:

    from trac.config import Option
    ...
    disable_wiki = Option('components', 'trac.wiki.web_ui.WikiModule', 'disabled',
        """Disable the Wiki module as needed for this version of Tags plugin.""")

Totally untested - may or may not work :-) Anyway, as I don't see that such auto-disable logic can be implemented in any sane manner, I propose a wontfix for this.

[Tim Hatch]

The ​TH:TagsPlugin for 0.11 doesn't require disabling anything, so this ticket could even be a worksforme.

[Christian Boos]

This reminds me of a discussion we had once about the default ticket group stats provider (#6232). I think we should have an easy way to subclass an existing module and allow the subclass to "take over". The approach suggested by osimons might work, another idea would be that the subclass could mark the base class as "abstract".

I'd rather close that ticket once we have a clear and defined way to achieve module sub-classing.