Ticket #2240 (closed enhancement: migrated)
Improve the config system of TG2
|Reported by:||chrisz||Owned by:|
The current configuration system of TG2 is somewhat confusing and error-prone.
Actually we have two configuration systems which in my view are both problematic: The *.ini files and the *_cfg.py files.
1) The problem with the *.ini files is that - unlike TG1 - the settings are not evaluated. So if you set my.setting = false, your setting will be actually the string 'false', not the boolean value False. Same problem for ints, lists or other Python objects. So you need to evaluate the config settings with functions like asbool() which is inconvenient, not performant and you can easily forget to do this.
2) The problem with the *._cfg.py is that you have to write base_config['my.setting'] = False instead of simply my.setting = false which is much clearer and easier to write if you have many settings. Also, persons who need to customize application specific settings may not always be Python coders and can easily mess up things in the *.py files.
But the main problem is that both syntax and semantics of the 2 config systems differ. I.e. if you move a setting from app_cfg.py to deployment.ini, then you need to change the notation and you need to change the way how you access the setting in your application in case it is not a string.
1) Use ConfigObj instead of ConfigParser for the *.ini files (maybe also rename them to *.cfg to make this change more obvious). Alternatively, use ConfigParser, but evaluate the settings immediately after reading the config file. This is also how it is done by CherryPy. This way the TG2 config system would also become more compatible with TG1 again.
2) Maybe add a file base_cfg.py that gets imported as base_config in app_cfg.py. Then you can simply set setting = False in base_cfg.py instead of base_config.setting = False in app_cfg.py.
3) Alternatively or in addition to base_cfg.py, there should be a normal app.ini resp. app.cfg file. In my projects I have many settings that are application specific, but need to be customized by the person who is deploying the application (who may not be a Python coder), not by an application developer.
- Version changed from 2.0b6 to trunk
- Milestone changed from __unclassified__ to 2.1