I like this idea as well. In fact, I use it in almost every other
project that I write. See, for example,
The .rimap file is pure Python.
The basic idea is to treat data (the configuration file) as code. It's
not new, and it has its drawbacks. Treating data as code is convenient,
in that you let the script engine do all the "hard" work for you. But,
it is considered harmful by the security minded: do you really want to
hand the keys to your interpretter to whomever provided the data? Do you
really want a configuration file that "computes" the configuration?
The reason that we're not doing an 'exec' on a configuration file is
because I was thinking ahead to a time when multiple users could share a
single Spyce server. This was at the time when people were still excited
about 'rexec', and sandboxed execution within Python seemed within
reach. We might wish to relax this constraint now, if there is some
advantage to doing so.
But, please note that most of the logic in spyceConfig.py is NOT the
parsing of the configuration file. That's done by the ConfigParser
module, and it's only a few lines. The logic in there is to take care of
overrides and/or defaults. And, the length of the code is due to the
fact that different parameters need different logic for this. It's
possible to collapse the parameters into categories that share the same
logic, and this would shorten the code considerably. Copy-paste seemed
easier at the time.
To summarize: I agree that the spyceConfig.py is getting a tad long for
the little functionality it provides. It could be significantly
compressed, I think, without resorting to code in the config file. I'm
open to the idea of code as a configuration file, but the ramifications
of a configuration program, rather than a configuration data file, need
to be justified.
All the best,
On Wed, 2 Mar 2005, Conan Albrecht wrote:
> I *really* like this idea. It goes very well with the "minimalistic"
> approach of Spyce. MoinMoin, a python-based wiki, already takes this
> approach and it works very well.
> Conan C. Albrecht, Ph.D.
> Brigham Young University
> On Mar 1, 2005, at 12:00 PM, Jonathan Ellis wrote:
>> I'd like to see a spyceconf.py instead of a spyce.conf. Besides removing
>> the need for a separate config parser it gets rid of the problems that
>> rolling your own configuration language gives you. For instance, one of my
>> spyce projects on my windows laptop has this path:
>> path: C:/Documents and Settings/Jonathan
>> Ellis/Desktop/projects/silentwhistle/trunk/sw3/modules;C:/Documents and
>> Settings/Jonathan Ellis/Desktop/projects/silentwhistle/trunk/survey3/src
>> Back before I started getting into Spyce internals, I tried quoting and
>> backslashing to escape the spaces before I finally tried just letting spyce
>> split on the semicolon. If it were simple python code:
>> path = ['C:/Documents .../modules', 'C:/Documents .../src']
>> this wouldn't ever be an issue.
>> As a minor benefit it would also simplify accessing spyce configuration
>> from non-spyce python modules; just "import spyceconfig" and away you go.