A standard config file per plugin

It occurred to me whilst unpicking a hardcoded path in a plugin, that plugins should ship with an overridable config file that it automatically loaded by the plugins system.

e.g.

lib/TWiki/Plugins/DirectedGraphPlugin/Setup.pm

Which would be overridden by the presence of:

lib/TWiki/Plugins/DirectedGraphPlugin/Setup.local.pm

With a bit of careful design, these Setup.local.pm files can be kept with the site and thus continue to override the supplied Setup.pm files.

We could equally use YAML or the suchlike.

-- MartinCleaver - 19 Apr 2005

I did some experimentation a while ago with PublishAddOn, making the install script prompt for values and adding the config directly to LocalSite.cfg. Try installing PublishAddOn on a DEVELOP checout to see how it works.

$cfg{PublishAddOn}{PublishDir} = '/full/path';
$cfg{PublishAddOn}{PublishUrl} = 'http://full/url';

The {PublishAddOn} part uniquely identifies this configuration as being associated with that plugin (c.f. $cfg{RCS} which configures the Store module). This approach has a number of significant advantages:

• Simple solution
• Familiar perl syntax
• Full power of perl to express configuration
• Configuration paradigm familiar to TWiki admins
• No need for a YAML parser
• Easy to separate plugin configuration from other config vars
• Keeps all config in one place
• Config appears in testenv
• Config is trivial to upgrade

I was planning to add support for this to the BuildContrib based on the POSTINSTALL I wrote for the PublishAddOn.

-- CrawfordCurrie - 19 Apr 2005

I like the idea. I assume you are referring to

    require "TWiki/Contrib/PublishAddOn/PublishAddOn.cfg";

(I could not see where this file was generated - I can't actually install it from where I am currently located.)

If so, that is a little different to your idea of extending the Cfg hash as described above (and I prefer the Cfg hash idea).

We could have a standard method in the plugins that initialises the variables, but call it from Plugins.pm in such a way that the Cfg variables override those specified in the method.

-- MartinCleaver - 19 Apr 2005

No. What is implemented in the BuildContrib is support for adding settings to LocalSite.cfg. First level keys in the config hash indicate the plugin e.g. $cfg{ElectricPlugin}. Second level and below is for the plugin to use as it sees fit. This avoids any complex jiggery-pokery and ultimately will lead to the settings being editable from the configuration screen (testenv).

-- CrawfordCurrie - 06 Jun 2005

Nice. I like it. How does a plugin enquire about its settings?

-- MartinCleaver - 06 Jun 2005

It references $TWiki::cfg{MyFirstPlugin}{MySetting}

The BuildContrib installer creates these values for Cairo and earlier as well, by appending them to TWiki.cfg.

-- CrawfordCurrie - 07 Jun 2005