Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).

Russel Winder may provide more insight into optimal plugin scheme following information from ToolsIndex.

I thought about using Abstract Base Classes as described here but there can be alternative (or more simple solutions). Trac component system is nice, but IMO not documented good enough for plugin writers, and it may be an overkill for our purposes, especially for debugging (like with any observers that are dynamically inserted). -- techtonik 2010-05-06 14:15:58

Russel Winder

Given the invitation above B)

The principle question is, what is a plugin. Currently SCons has just infrastructure and tools. Currently all infrastructure and most tools are provided as part of the core SCons. Although the core tools are realized using Python modules, SCons allows for tools to be realized as Python packages as well. This means that tools can be developed (though not currently tested :-( ) separately from the SCons core. So if plugin means a SCons tool then SCons already has a plugin capability. The API is not flexible and possible needs a rethink, but it is there. If however, plugin should mean more than a SCons tool, the core infrastructure of SCons would need a rework (I guess).

I guess we could address this by asking "For what do we need plugins with SCons?". Supporting new languages is handled by the tool idea, so that is covered already. What other things might plugins be developed to do? If we can enumerate a few exemplars, it might give us an idea of what the API should look like.

Russel Winder 2010-05-07 07:04:47

NB Its a pity MoinMoin doesn't implement ISO8601 for its timestamps :-(

PluginArchitecture (last edited 2010-05-08 17:00:22 by RusselWinder)