For our Python scripts we have used a fair number of idioms and variations such as importing a config.py file with the parameters as module global vars or importing the content of a dictionary. A different one we used lately is very useful and simple:
# This should be your program using the config
import os
class config :
#Here we define the default parameters
paramA = "value A"
paramC = "value C"
class category1 :
paramC="value sub C"
#Here we load new values from files, if they exist
for configFile in [
"/usr/share/myprog/defaultconfig",
"/etc/myprog.conf",
"~/.myprog/config",
"myconfig.conf",
] :
if not os.access(configFile,os.R_OK) : continue
execfile(configFile)
# That's the config params usage. Pretty!
print config.paramA
print config.paramB
print config.paramC
print config.category1.paramC
print "This is a template: %(paramC)s" % config.category1.__dict__
If you write in the config file this:
# myconfig.conf
paramA="new value A"
paramB="new value B"
category1.paramC="new subCvalue"
paramB+=" extension " + paramA
you'll get this
new value A
new value B extension new value A
value C
new subCvalue
This is a template: new subCvalue
The config file is read as you were adding code at the same indentation level you have on the 'execfile' call.
Notice the advantages:
- Your config file looks like var assignations
- You can use inner classes to build up categories
- You can have a list of configuration locations with different precedence
- You can include almost whatever python code
- You can do templating with the params getting a dictionary like config.__dict__ or config.category1.__dict__
- You can put config checking code after loading.
Be carefull on unreliable contexts:
- Malicious config files can include almost whatever python code
- Config syntax errors crash the program (i guess that can be solved)
- Config files may add any new attribute, category, or method you didn't have
But if you are just managing your own utility scripts like us, that idiom is fantastic.