TWiki Extension Installer

The existing Plugin installer is a good start, but has some limitations that asks for ImprovePluginsInstaller.

What we need is an infrastructure to install Plugins, Contribs and TWikiApplications from TWiki.org's Plugins web. What I envision is a web-based TWiki extension installer where you can:

1. Define and package a TWiki extension:
   • Define install wizard screens with:
     • Destination web (optional)
     • Destination base topic name (optional)
     • Insert app into base topic (yes/no)
     • Destination URL
   • Dependencies on other TWiki packages
   • Distinguishes between files to always overwrite, and files to copy only if not exist
2. Install a package by simply clicking on an install link that:
   • Shows wizard screens (if defined)
   • Installs files (topics, attachments, libs)
   • Intelligently updates Plugin settings
   • Adds extension specific configuration items (that are picked up transparently by the configure script)

Example: The MeetingMinutes application is typically added to an existing project. The wizard asks for destination web (such as Tuna) and base topic name (such as FishSlicer), and installs the application:

• Add the meeting minutes form & list into the Tuna.FishSlicer topic
• Copies Tuna.FishSlicerMeetingTemplate

-- PeterThoeny - 16 Mar 2006

Which plugin installer are you referring to? TWikiInstallerContrib or the installer written by BuildContrib?

The model for plugin/extension management we have been using is firefox/thunderbird. A screen-driven installer as you describe would be most welcome; Will and I have been concentrating on the underlying infrastructure. Some observations:

• Being able to install a TWikiApplication to a single web may not be enough, especially if it is designed to work over several webs. It would be better for the PREINSTALL of the TWikiApplication to make that call.
• Plugins and Contribs muct be installed to {SystemWebName}.
• Using TWiki variables for configuration settings has a multitude of issues, and needs to be rethought. The logical thing to do is to write configuration settings to files in conf, and that is why Rafael created that directory. Config vars set this way should then be (selectively) overridden at web/topic level. From a performance perspective, we really, really, really need to stop reading Plugins topics.
• This implies the need for an API to read TWiki::cfg
  • New plugins can use $TWiki::cfg directly
  • The existing getPreferencesValue API can easily be modified to check $TWiki::cfg for older plugins.
  • %CFG{"name"}% has been suggested for use in topics. My only concern with this would be security.
• The installer script can maintain Cairo compatibility if you write it to add plugin settings direct to plugins topics for pre-Dakar installs. Though I personally don't think it's worth the (considerable) effort.
• Dependencies are already handled by the BuildContrib installer. It should be straightforward to extend that to a web interface.
• There needs to be a way to deal with the fact that some CPAN dependencies (e.g. Storable) are not trivial to install, either because they require compilation, or because the tests fail.

-- CrawfordCurrie - 16 Mar 2006