Item8979: Dependency check fails if target module is installed, but fails to load due to missing dependencies.

The Find Extensions function does not detect that LdapContrib is installed. Reported in Support.Question514 and confirmed that also fails on trunk with the new extension installer code.

-- GeorgeClark - 05 May 2010

Problem is most likely in Dependencies.pm. Because LdapContrib is missing dependencies, the "require" for LdapContrib fails, and Dependencies is unable to report the installed version of LdapContrib.

-- GeorgeClark - 05 May 2010

For me, the correct fix would be to stop assuming users are clever enough to READ the screen, and make the installer abort with a huge red flashing error when a dependency marked as Required fails.

-- OlivierRaginel - 05 May 2010

The problem is deeper than that because Dependency.pm incorrectly reports that an extension is not installed, when the actual status is that the module is installed, but failing due to missing dependencies. From IRC:

(12:56:27 PM) Babar: check the error code for the eval?
(12:57:02 PM) gac410: Yes - but if the module doesn't load, no way to check the VERSION or RELEASE strings.
(12:57:58 PM) Babar: then LdapContrib should be more clever, not Dependency.pm
(12:58:09 PM) gac410: Wondering if Extensions should "eval" their dependencies in init 
(12:58:11 PM) Babar: it should try to load the modules, and if it failts, report, instead of crashing
(12:58:39 PM) Babar: but honestly, that's a pain...
(12:59:37 PM) gac410: Side effect is the support question,  and bin/configure doesn't show extension as installed,  and installer might install multiple times because install check always fails.
(01:00:01 PM) gac410: Opened Tasks:8979
(01:00:04 PM) foswikibot_: http://foswiki.org/Tasks/Item8979
(01:00:06 PM) Babar: installer checks dependencies
(01:00:18 PM) Babar: if they fail, it could abort
(01:00:45 PM) gac410: Not good - because CPAN dependencies are never installed online,  and optionally installed at tail end of shell 
(01:01:26 PM) gac410: Big change if we refuse to install if dep's are missing. 
(01:01:52 PM) gac410: At least issue exists on Release branch as well as trunk, so I didn't make it worse :-)
(01:02:50 PM) gac410: And have to invert the shell installer, install CPAN first, and then go ahead with extension installs.
(01:02:55 PM) Babar: then maybe at least return some big fat warning that one has to install these dependencies
(01:03:09 PM) gac410: I do.   That's covered. 
(01:03:42 PM) gac410: One issue is that if user goes back in to look,  it appears as though the Extension was never installed.  
(01:04:40 PM) Babar: then there is a simple fix
(01:04:52 PM) Babar: if the require fail, test if the file exists
(01:05:01 PM) Babar: if it exists, show it as installed but not working
(01:05:28 PM) gac410: Yes - and also extract the VERSION / RELEASE with a regex so that test can proceed
(01:05:55 PM) Babar: yeah, good idea

-- GeorgeClark - 05 May 2010

Ok, as George pointed out, he already did that, but we can:

• Try to require the plugin
• check the error code for the eval?
• if that fails, check if the file exists (the s/::/\//g + .pm)
• if that fails, assume the extension is not installed
• if that succeeds, parse the .pm to extract VERSION and RELEASE

-- OlivierRaginel - 05 May 2010

Fixed on trunk. 1.0.9 doesn't have dependency.pm, so it will require a different fix.

-- GeorgeClark - 10 May 2010

On 1.0.9, EXTENSIONS.pm recovers the installed version from the Extension topic, not the module, provided that the module is compilable. Added an exception to the test to flag the module as compilable as long as the error is not that the primary module was not found.

-- GeorgeClark - 10 May 2010

Commenting is disabled while not logged in