[Dirvish] the Options hash, and a testing dilemma
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
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
> 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
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.
More information about the Dirvish