Configuration management is an important aspect of any application. Configuration is necessary unless the application in question is a monolithic, inflexible piece of code. And, there are applications such as these but they aren't the norm. Many aspects of most applications will need to change, even if only subtly. The users running these applications need an easy way to manage and manipulate these configuration values.
The INI configuration style is probably the best standard to follow. It is easy for both users and applications to understand and to manipulate. Moreover, there exist libraries for handling these files in almost any programming language.
In Python, the ConfigObj package is good at dealing with configuration files. It is good at both reading and manipulating the files which is useful because developers need not depend on one package for reading configuration files and another for writing them. There is a single class that Python applications should be concerned with in the ConfigObj package. The configuration objects are instantiated with the file name containing the configuration.
Perhaps the best feature of ConfigObj instances is that configuration values can be read and written using dictionary style notation. This is much more intuitive for Python developers than using some kind of configuration specific notation.
However, since the configuration values are accessed using dictionary notation, it would be trivially easy to abstract away the configuration values as attributes of some domain specific class. The same configuration file may in fact be read by various domain classes. Each class reading a different section of the configuration.
Showing posts with label configobj. Show all posts
Showing posts with label configobj. Show all posts
Friday, October 9, 2009
Tuesday, November 4, 2008
Some TurboGears configuration thoughts
The TurboGears Python web framework uses Cherrypy as the web server. Cherrypy offers several other useful features other than strictly "web server" functionality. One of these features is project configuration. TurboGears basically builds on the Cherrypy configuration functionality. TurboGears also uses a Python package called ConfigObj to help distribute responsibilities. If there is one thing the TurboGears project does well, it would have to be reusing existing functionality rather than rebuild it.
When retrieving a configuration value in a TurboGears project using get(), TurboGears simply uses the Cherrypy configuration. However, the TurboGears framework is responsible for keeping the Cherrypy configuration component up to date. For example, lets say you need to update the project configuration dynamically as the result of some client request. This can be done is one of two ways. The first, you could pass a key/value dictionary to update(). The second, you could pass a configuration file to update_config(). In both cases, we are essentially updating the Cherrypy configuration. The ConfigObj package comes in handy when we need to read configuration files. Not when we already have a key/value configuration dictionary.
My main criticism of the TurboGears config module is that I wish there were a factory function that simply generated a configuration instance. This instance would be a representation of the configuration for the entire project. All the functions that are currently defined in the TurboGears config module could be instance methods of this new configuration class. I haven't yet looked in the trunk yet to see whats happening there with the config module.
When retrieving a configuration value in a TurboGears project using get(), TurboGears simply uses the Cherrypy configuration. However, the TurboGears framework is responsible for keeping the Cherrypy configuration component up to date. For example, lets say you need to update the project configuration dynamically as the result of some client request. This can be done is one of two ways. The first, you could pass a key/value dictionary to update(). The second, you could pass a configuration file to update_config(). In both cases, we are essentially updating the Cherrypy configuration. The ConfigObj package comes in handy when we need to read configuration files. Not when we already have a key/value configuration dictionary.
My main criticism of the TurboGears config module is that I wish there were a factory function that simply generated a configuration instance. This instance would be a representation of the configuration for the entire project. All the functions that are currently defined in the TurboGears config module could be instance methods of this new configuration class. I haven't yet looked in the trunk yet to see whats happening there with the config module.
Subscribe to:
Posts
(
Atom
)