[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