Item9232: configure Checkers docco too sparse

I finally started to try to work out how to get configure to guess a value for a setting, and got so far as to think that I can only hack it into a setting's Checker::check() sub

BUT, the only docco I can find, is this small snippet in configure.

#    Checkers - are specialised UIs designed to give checking support for
#          variable values. Checkers also include the read-only checking
#          UIs used for checking environment.

additionally, I am unsure how this readonly check can possibly trigger the Checkers::guessed.

looking further, there is a clear and desperate need for rationalisation here - there is

$Foswiki::cfg{Store}{Implementation} = 'Foswiki::Store::RcsWrap';
$Foswiki::cfg{Store}{Implementation} = 'Foswiki::Store::RcsLite' if ($^O eq 'MSWin32');

in Foswiki.spec - I think i did that last week quickly

and

###########################################################
# Grope the OS. This duplicates a bit of code in Foswiki.pm,
# but it has to be duplicated because we don't want to deal
# with loading Foswiki just yet.

unless ( $Foswiki::cfg{DetailedOS} ) {
    $Foswiki::cfg{DetailedOS} = $^O;
    unless ( $Foswiki::cfg{DetailedOS} ) {
        require Config;
        $Foswiki::cfg{DetailedOS} = $Config::Config{osname};
    }
}
unless ( $Foswiki::cfg{OS} ) {
    if ( $Foswiki::cfg{DetailedOS} =~ /darwin/i ) {    # MacOS X

in configure itself - this i assume could be tossed off into a OSChecker and DetailedOSChecker and still work?

and (as the comment in the code above says) the same thing in Foswiki.pm again

I presume that there is no protection to stop someone from misusing a checker to set a value - making it a very soft non-verbal contract

---

so, given that its a bit fuzzy, what is the right way for configure to create the htpasswd file when ApacheHtpasswd is selected - to avoid the breakage as raised in Item2484, or to set a default for grep that is conditional on OS - I actually want to implement Item800 for windows, OSX and possibly solaris (where it'll need to be in /opt/csw or something else weird).

Crawford - what i'm looking for is advise on the right direction - imo we would be best off with a Checker::guess class method that can be used to set a value before the checker is run, but in many ways its a duplication, and thus could just be expediently put into the checker - but I've not found the guidance about what can be done, and what direction the design should go.

-- SvenDowideit - 01 Jul 2010

OK, the comment is wrong (ish). Checkers were originally intended to be read-only, but I hacked in the guessing under pressure, and didn't update the comment. Checker::guessed is invoked by Checker::check when it finds a value that requires, but hasn't been provided with, a default. For example, looking at DispScriptUrlPath

    if ( !defined($val) || $val eq 'NOT SET' ) {
        $Foswiki::cfg{DispScriptUrlPath} = $Foswiki::cfg{ScriptUrlPath};
        return $this->guessed(0);
    }

The NOT SET is automatically assigned in BasicSanity when a required or all else fails setting isn't found (currently DataDir DefaultUrlHost PubUrlPath PubDir TemplateDir ScriptUrlPath LocalesDir). In this case this part of the condition will never fire, but if !defined($val) it will still guess that $Foswiki::cfg{DispScriptUrlPath} = $Foswiki::cfg{ScriptUrlPath}.

I don't see any good reason to separate the checker and the guesser, as the guesser would have to check to decide whether it needs to guess or not. In the example you give, creating the .htpasswd file should be done in the checker but be warned that creating files from checkers is always a hit-and-miss business, as you can't be guaranteed permissions will either allow it, or be right when you have finished.

-- CrawfordCurrie - 01 Jul 2010

aha. mmm, there are parameters to Checker::check($value, $root) - i presume they also don't actually exist?

-- SvenDowideit - 03 Jul 2010

Added oodles of doc, and refactored some overdue refactorings.

-- CrawfordCurrie - 04 Jul 2010

and breaking configure...

Failed to load the perl module Foswiki::Configure::FoswikiCfg. The module was found at C:\src\svn.foswiki.org\trunk\core\lib/Foswiki/Configure/FoswikiCfg.pm

Please ensure that:
   1 Foswiki::Configure::FoswikiCfg is installed,
   2 that the module is available on the @INC path,
   3 that the webserver user (SYSTEM) has permission to read the Foswiki/Configure/FoswikiCfg.pm file.
The detailed error seen was:
Can't locate Foswiki/Configure/Visitor.pm in @INC (@INC contains: C:\src\svn.foswiki.org\trunk\core\lib . C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib C:\src\svn.foswiki.org\trunk\core\lib/CPAN/lib//arch C:\src\svn.foswiki.org\trunk\core\lib/CPAN/lib//5.12.0/MSWin32-x86-multi-thread C:\src\svn.foswiki.org\trunk\core\lib/CPAN/lib//5.12.0 C:\src\svn.foswiki.org\trunk\core\lib/CPAN/lib/) at C:\src\svn.foswiki.org\trunk\core\lib/Foswiki/Configure/FoswikiCfg.pm line 67.
BEGIN failed--compilation aborted at C:\src\svn.foswiki.org\trunk\core\lib/Foswiki/Configure/FoswikiCfg.pm line 67.
Compilation failed in require at (eval 40) line 2.
BEGIN failed--compilation aborted at (eval 40) line 2.

-- SvenDowideit - 04 Jul 2010

mea culpa

-- CrawfordCurrie - 05 Jul 2010

and again !

and then in trying to work through, its pretty clear that your changes have no place this late in a feature freeze. There are pretty major structural changes that are not complete.

reverting. Please separate docco from refactoring and wait until an appropriate time to destableise the code.

-- SvenDowideit - 06 Jul 2010

Checked in the missing file. It was an empty class, there just to provide a hook for doc.

I'm missing what changes you think are causing such damage (other than failing to check in those two files, for which I apologise). I saw your MSWin32 conditions, and was somewhat surprised you had made them work, as the Foswiki.spec (and LocalSite.cfg) should never contain functional code. The reason is that those files are parsed in a non-perl-parser way and the moronic parser assumes the simple format described. Redefining a config item is not something I ever tried. However AFAIK I haven't changed any code that would change the behaviour. If you can explain to me what you are trying to do (and why you are not doing it in a Checker) I'd be delighted to help.

Later: while trying to understand the taint error you reported, I discovered that:

$x =~ s/y/eval("z")/ge

will taint $x but only if y is seen in it (logical, I guess). This makes this expression highly sensitive to the contents of the LocalSite.cfg and .spec files. FWIW this bug was there before I touched anything.

-- CrawfordCurrie - 06 Jul 2010

I think the damage is precisly that you've shown its not as simple as you think - it took you 3 days to get it working, and no-one knows what other wrinkles will be found.

I just reported and commited a workaround for another new configure crash - you've obviously changed much more than you even know.

I didn't do it in a Checker because that didn't work - the minimal no cfg screen only executes a small subset of the checkers, and not knowing the OS caused un-necessary crashes - that said, LocalSite.cfg has always had executable perl in it - though less and less over time.

as to explaining what I'm trying to do - I'm trying hard to get enough information about what the configure design and implementation does and can do, so that I know what I can expect to acheive, and what I'll need to hack around.

-- SvenDowideit - 08 Jul 2010

I've done my best on the docco, and repaired my mistakes (none of which were functional changes, just typos on my part, but that's another story) so I'm closing this. If the doc still doesn't cut it, let me know where and I can always take another pass.

-- CrawfordCurrie - 12 Jul 2010

Commenting is disabled while not logged in