Feature Proposal: Deprecate the executable code in the *_installer files

Motivation

This code is hard coded to the relative location of the tools directory, and cannot easily be changed. Changing this installer shim means re-releasing every extension to accomplish the update. Some newer techniques for managing multiple-hostname installations use environment variables to locate directories and we can't easily make that backwards compatible to the existing distributed installer files.

Description and Documentation

Remove the self-executing code from the _installer packages for future released extensions and remove the instructions to download and run the _installer file. Enhance the generic tools/extension_installer.pl file to be usable when LocalSite.cfg contains "relative specifications" per Tasks.Item10940

This also makes it easier to further enhance the CLI based installers. By distributing code in every _installer file, bug fixes and enhancements are difficult to implement. It supports the proposal UseEnhanceAndMoveSpecFiles.

Examples

The CLI installation would change:

Current method

• Download the DesiredExtension_installer file and optionally the DesiredExtension.tgz file
• Change to the root of the foswiki installation and run perl DesiredExtension _installer

Proposed method for default installations

• Change to the root of the foswiki installation
• Optionally download the DesiredExtension.tgz file
• Run perl tools/extension_installer DesiredExtension

Method used with relocated directories

• Optionally download the DesiredExtension.tgz file to the root of the Foswiki installatoin
• Change to the bin or cgi-bin directory.
• Run perl path_to/tools/extension_installer DesiredExtension

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

• tools/extension_installer will be changed to look first in the "current directory" for setlib.cfg and if present, use it to locate all other directories as the CGI scripts do today.
• If setlib.cfg is not found in the current directory, the installer will attempt to find lib/LocalSite.cfg relative to the current directory and extract the ScriptDir from that file as is currently done.

-- Contributors: GeorgeClark - 06 Jul 2011

Discussion

rather than enhancing tools/extension_installer, can we instead rename it and make it a shim to the Configure libraries, so it re-uses that code, and adds support to enable plugins? (and Thus pave the way to add fully command line support for setting cfg params?)

The fact that configure is the only way to get a correct cfg file, and is only web based is causing issues for the (small) group of users that prefer to secure that end of things by avoiding web access, and has made it much harder to make platform packages.

I'm willing to help - especially at the end goal that the one configure tool can replace pseudo-install etc (via a lib/Configure/PseudoInstal.pml optional lib..)

-- SvenDowideit - 07 Jul 2011

Well, the first step is to deprecate the *_installer code. Then we can do lots of stuff to extensions_installer, or configure. What will a command line look like? Do you envision a shell with sub-commands, individual commands like git.

   foswiki install SomeExtension [enable]
   foswiki enable SomeExtension
   foswiki remove SomeExtension
   foswiki show [tab] [info] [expert]          (ex  foswiki show store expert )
   foswiki set {EnableHierarchicalWebs} enabled
   foswiki clear {HomeTopicName}    (restores the default)

-- GeorgeClark - 07 Jul 2011

Marking this as a DiscardedProposal. The tools/configure CLI tool now can install extensions, and the _installer file is now a shim that calls the tools/configure wizards. Most of the above information is obsolete.

-- Main.GeorgeClark - 08 Feb 2018 - 16:56