[Dirvish] the Options hash, and a testing dilemma

Eric Mountain em-dirvish-1 at nerim.net
Thu Feb 10 15:00:46 PST 2005


On Wednesday 09 Feb 2005 02:25, Keith Lofstrom spake thus:
> Those of you who have studied the Dirvish code have encountered the
> infamous $Options hash.   In the instruction flow through the "dirvish"
> routine (assembled by the INSTALL script out of dirvish.pl and
> loadconfig.pl, with the $CONFDIR prepended) it contains some anonymous

The install script is something that needs to go away in its present form.  
OK, maybe keep it in the next stable release, but deprecate it and remove it 
in the following stable release.  We really need to target a "standard" 
install method along the lines of what has previously been discussed on the 
list.

This means finding a nice way to deal with $CONFDIR, and factoring it out into 
a separate Perl module so that at least if we have to keep it there is just 
one place to look (and update when installing the code, rather than updating 
every script).

> The options are first set by the $CONFDIR.conf or $CONFDIR/master.conf .
> Then the perl module GetOptions is called, which sets more options, and
> possibly loads more config files as indicated above.  Pretty squirrely.
>
> There is a problem with this - it always assumes there is a valid
> master configuration file - and this is needed before options processing
> begins, so that we know where the banks and vaults are.  But what if
> you want to use a specialized master.conf file for testing during
> installation?

This is a pb even during development.

> The master.conf file will either be left over from 
> a previous install (not to be modified!) or will be part of this
> install, and not customized to the system.
>
> I suggest adding an additional option, --cleanoptions .  When this
> option is encountered, we run an anonymous subroutine that cleans
> out the $Options hash (and any previous options - we restore to
> the original $Options contents.   That can be followed with a
> --config=test.conf option, which can fill in all the options that
> you might normally expect to find in master.conf, except customized
> for testing.

An alternative is to arrange for $CONFDIR to be set differently when testing.  
For instance, it could be set from an environment variable if that variable 
happens to be defined.  No impact to existing installations, no 
backward-incompatible change. Plus, you get to test with the same code and 
options as you would run with once installed.  Finally, no extra option with 
strange side-effects... after all, people would just say, "well hey, why read 
the config file in the first place if you're just going to discard the 
contents anyway".  Also, it means the script will run correctly even if a bad 
master config file exists in the "normal" CONFDIR location.

> I would like to see GetOptions processed
> before we read any configuration files at all, but I cannot see how
> to do that without changing the existing runtime behavior.  That would
> be unacceptable.

Dirvish's behaviour in this respect is totally non-standard and off-putting.  
It may be in Dirvish's interest to eventually break backward compatibility 
one day to fix this.

-- 
Eric Mountain


More information about the Dirvish mailing list