Feature Proposal: It is helpful to upgraders to know which package Foswiki uses for each plugin

Motivation

Old debian installations symlinked twiki/lib to the system's perl lib directories, so all of the twiki plugins are accessible via the perl library path. This causes a problem when upgrading to Foswiki.

If you install a Foswiki version of a plugin previously installed on the old wiki, then configure may choose the TWiki::Plugins:: package instead of the Foswiki::Plugins:: package.

The plugin may even appear to work (thanks to the TWikiCompatibilityPlugin). However, there may be problems. For example, I found that ActionTrackerPlugin did not process %<nop>ENDACTION%. This is hard to debug because the Foswiki::Plugins::ActionTrackerPlugin.pm (for example) is installed, but not used. I added debug code to the Foswiki plugin that I had just installed, but it was not executed because that module was not being used.

The information is available via configure, as an expert option, if you know where to look and think to look there.

However, all this frustration would be avoided if Foswiki made it clear which package is being used for each plugin. That would lower the bar for upgraders, which is a Good Thing.

Description and Documentation

Here are a few options:

Plugin installer "primes" configure

The plugin installer could store somewhere that a Foswiki version of a plugin has just been installed, so that when the admin enables the plugin in configure, the package just-installed is selected automatically. (This could also work the other way - if an old version is installed, then that version's package could be preselected instead.)

One way to do this would be for the installer to set the package in LocalSite.cfg (perhaps by appending to it).

configure warning

configure could generate a warning if both TWiki and Foswiki versions of a plugin are visible to configure, and the TWiki:: package is being used.

This was done in 1.1. Configure will warn if multiple versions are found of a plugin in the libpath or if the Foswiki version is available, but the TWiki version is active. -- GeorgeClark - 07 Dec 2010

Additional info on InstalledPlugins

The %<nop>FAILEDPLUGINS% already provides more diagnostic information than a simple failure/status report. An additional column could be added to the first table, like this:

Plugin	Errors	Package
ActionTrackerPlugin	none	TWiki::Plugins::ActionTrackerPlugin
TWikiCompatibilityPlugin	none	Foswiki::Plugins::TWikiCompatibilityPlugin
SpreadSheetPlugin	none	Foswiki::Plugins::SpreadSheetPlugin

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MichaelTempest - 30 Nov 2009

Discussion

I've described the problem and provided a few examples on how the problem might be resolved. Hopefully someone will have the Better Idea

-- MichaelTempest - 30 Nov 2009

The "general problem" is when the code you are executing is not the code you expect. This can come about through several errors; the one you mention, but also erroneous manual installs, different environment between installer and webserver user, etc.

It's not enough to show the package, as the same package might exist in several places on the @INC path. The only way to know what is really being executed would be for InstalledPlugins to search @INC and report the filesystem path to the package.

DONE in a Config checker -- GeorgeClark - 07 Dec 2010

-- CrawfordCurrie - 04 Dec 2009

Agreed. As you say, this would address my problem and several others beside.

I think the path information should only be shown on InstalledPlugins if the current user is an admin user.

-- MichaelTempest - 05 Dec 2009

See also Development/UseEnhanceAndMoveSpecFiles - I wonder if the external package managers should load the Foswiki package into a staging directory and then run the _installer script to actually populate the web, etc. It solves the issue with sites that rename webs, topics, etc. And can better address merging in the Config.spec, enabling the plugin, etc. It also takes a backup before modifying files that might have been locally modified.

Actually I'll put myself as a committed developer for this - The only missing piece from your request is to add the Plugin module path to the diagnostics page. Rather than add it as a new column, I'll add it below the plugin name if the user is an admin. Seems to be simple enough. I've got it working but need to add an admin check. 1.1.3 unless Lavr releases inside the 14 day clock, then 1.1.4 or 1.2

-- GeorgeClark - 07 Dec 2010

I plan to release a 1.1.3 in around 2 weeks from now.

Can this wait till 1.1.4? There is always something we miss when we change configure changes. It is time consuming for the rest of us to test plugin upgrading because you have to make a copy of an installation each time and then try the upgrade and then revert back again before you can try again so we always end up with only the developer and maybe one more testing these features. And if we only have a few days and then we are all busy with family during the holiday season.

I prefer to wait so we have time. We have a good healthy backlog of fixed Items for 1.1.3 so better keep it stable than risk missing something that is not really an urgent and critical bug.

-- KennethLavrsen - 07 Dec 2010

1.1.4 it is. I'll commit to trunk and revert if anyone objects. It's a pretty trivial change and probably doesn't really need a feature request. But it will let us implement this one and close it out.

-- GeorgeClark - 08 Dec 2010