[kforge-dev] Changing configuration file from .ini format to python class
Rufus Pollock
rufus.pollock at okfn.org
Sun Aug 27 14:52:21 UTC 2006
Configuration files are common to most applications and KForge is no
exception. In fact any application built on dm at the very least will
need to load it database config from some external user-edited file.
At present we use .ini style configuration files that can be parsed by
python's ConfigParser module. The information so contained along with
some application-defined defaults are then loaded into the system
dictionary. The system dictionary is then used by all other parts of the
application to access this configuration data. When used for KForge this
worked fine (other than the ususal gripes about the ConfigParser
interface and features! See the python wiki[1] and this thread[2]).
[1]:http://wiki.python.org/moin/ConfigParserShootout
[2]:http://mail.python.org/pipermail/python-dev/2006-January/060138.html
However now that we have several different applications (KForge and CKAN
and possibly more) all of which use Domain Model we have the added
problem of repetition: common configuration variables for domain model
reappear must be inserted into kforge, ckan etc. This is because there
is no way to 'inherit' configuration using ini files (there is some very
limited inheritenace can be achieved by setting 'DEFAULT' section values
in code).
One obvious way to address this would be to adopt configuration that was
a python class (stored in a python module). This is quite a common
approach for python applications and is used, by among others, mailman,
moinmoin and django. The main inspiration here would be moinmoin.
Pros:
* Full power of python inheritance. This allows inheritance of
configuration from domain model to clients of domain model *and* for
easier overriding by users (i.e. a user of kforge can just inherit from
the standard kforge configuration overriding those variables they want)
* simple to use for basic attributes while supporting the full set of
python datatypes (don't have to do any parsing to convert a config file
list to a python list or 'True' to a boolean)
* doesn't require anything outside of the standard python distribution
Cons:
* More complexity to discover and access config file (can't just
point at a file but need to add the directory to the path and then do
import xxx).
* This problem can probably be solved fairly easily
* User may need to have some understanding of python
types
* Not sure this is a 'con' as using python may be more
understandable than a .ini config file where you write x = 9 and x = a
long string rather than x = 9 and x = 'a long string')
* No validation/specification (as provided by e.g. cfgparse[3]).
* Specification and validation not provided by ConfigParser module
and only available by modules outside of the standard distribution.
Furthermore this seems to be an additional feature separate from the
specification of the configuration file format itself.
[3]:http://cfgparse.sourceforge.net/
Thus overall I think that moving to configuration files using python
classes would offer significant advantages. Suggested implementation
would be something like:
1. Create dm.config module containing
{{{
class ConfigSection(object):
"""Dummy class to allow sections in config as in section.attribute.
"""
class ServiceConfig(object):
"""Configuration for an application service.
"""
system_name = 'dm'
db = ConfigSection()
db.name = 'dmtest'
db.user = 'dmuser'
}}}
2. (this is for kforge) Create kforge.config module containing
{{{
class ServiceConfig(dm.config.ServiceConfig):
system_name = 'kforge'
}}}
3. A user would then create there own module called mykforgeconfig.py
somewhere on disk consisting of
{{{
class ServiceConfig(kforge.config.ServiceConfig):
# override various attributes e.g.
# db.name = 'blah'
}}}
What do people think of this? Does it sound better than what we have and
are there any problems with the suggested approach for implementation?
Regards,
Rufus
More information about the kforge-dev
mailing list