Plugin Config in LocalSite.cfg

I'd like a place to put a plugins' configuration, in particular paths to depended executables. In many cases these would have to be not overridable in the plugin page.

One way to do this might be to have plugins specifying config variables in a default-providing plugin-bundled plugin.cfg. When activated in configure this would loads its defaults into LocalSite.cfg. They would be FINALPREFERENCES that cannot be overridden later.

The plugin config would be scope-checked/prefixed with the plugin name to ensure it can only specify variables in the namespace of the plugin.

This way all configuration for the site ends up in LocalSite.cfg, and is editable from bin/configure.

Thoughts?

-- MartinCleaver - 06 Aug 2005

this is a variation on our plan It should be implied in some of the discussions on irc

so to sum up - Yes so do we, but its a Edin* thing, as there is alot of mucking around we have to do

-- SvenDowideit - 07 Aug 2005

Atcherley it's a Dakar thing.

Build.pm (the plugins build module) already supports the addition of config options to LocalSite.cfg (and their removal when the uninstaller is run). For example, say you wanted to configure the "ImageMangler" executable for ImageManglerPlugin. The POSTINSTALL for ImageManglerPlugin might contain:

    print "* Enter the full absolute path to the ImageMangler executable";
    while (1) {
        my $im = prompt('Full path to ImageMangler executable');
        if( -x $im ) {
            print STDERR "$im does not exist or is not executable";
        } else {
            setConfig( 'ImageManglerPlugin', Executable => $im );
            last;
        }
    }

$TWiki::cfg{ImageManglerPlugin}{Executable} = 'path to program';

If you choose not to use BuildContrib, you can always write full instructions to the installer in your plugin document as to how to edit LocalSite.cfg.

Note that configure is data-driven, so installers can also insert lines into LocalSite.cfg that allow configure to create entries in the configure screen for the plugins. For example, POSTINSTALL might contain:

            commentConfig( <<__COMMENT__
# **PATH**
# This is the full, absolute path to the Image Mangler executable
__COMMENT__
            setConfig( 'ImageManglerPlugin', Executable => $im );

# **PATH**
# This is the full, absolute path to the Image Mangler executable
$TWiki::cfg{ImageManglerPlugin}{Executable} = 'path to program';

-- CrawfordCurrie - 11 Aug 2005

Sounds all good except the: > removal when the uninstaller is run

Might the admin's config options be needed back when the plugin is reinstalled?

-- MartinCleaver - 11 Aug 2005 Huh? Since the uninstaller deletes all the code and documentation for the plugin, it seems a bit pointless leaving the config behind.

-- CrawfordCurrie - 12 Aug 2005

i suppose it would be useful if you later decide to reinstall the plugin?

-- WillNorris - 12 Aug 2005

What about saving the config before uninstalling? That way it's easy to recover it in case of reinstallation.

-- RafaelAlvarez - 12 Aug 2005

No. Sorry, but if you uninstall a plugin, it's uninstalled, and the config dies. Backing up the config is your problem; let's keep it simple, please.

-- CrawfordCurrie - 23 Aug 2005

If the configs (one per plugin) were topics in an admin-only web we could use TWiki to revision control the backups.

-- MartinCleaver - 02 Oct 2005

True. But then we'd be doubling the overhead to 2 topic reads per plugin, when we're trying to reduce it to none.

-- CrawfordCurrie - 02 Oct 2005

Perhaps we just back up per-plugin configs to that web. Live stuff stays in LocalSite.cfg

-- MartinCleaver - 02 Oct 2005

seems very complicated when an uninstall could simply set $TWiki::cfg{Plugins}{name}{Enabled} to 0 and leave the rest of the settings alone.

-- WillNorris - 02 Oct 2005

True, I can't see why it has to delete the old settings. Perhaps we need a way to revert to the plugins' defaults? That'd be useful anyway with configure... soooner or later someone is going to get lost in all the options.

-- MartinCleaver - 02 Oct 2005

Martin, sounds to me like you're very interested in working on adding features to configure in Edinborough thats a good thing!

-- SvenDowideit - 02 Oct 2005