|
From: Jeffrey B. <jef...@ea...> - 2007-11-06 02:25:45
|
When I needed a way to specify configuration parameters for my program, I chose ConfigObj without looking closely at ConfigParser very closely because I had a feeling ConfigObj was better. Recently, I started using the logging package with my software. It allows me to specify its configuration using a configuration file, but it uses ConfigParser to access it. I would like to keep all configuration data in one configuration file, so I figured that it wouldn't be a big deal to switch my software over to ConfigParser. When I first encountered get/set, my stomach twisted. When I discovered that I couldn't specify a list as an option, I aborted. I was transforming code that was simple and transparent into something verbose and opaque. Because my configuration file is not compatible with ConfigParser, I am resigned to two configuration files, one for my code and one for logging. However, I am wondering first whether I am missing a one-configuration-file solution. I suppose that logging needs to be updated to use ConfigObj, but perhaps I am missing a solution that I can apply more readily. -- Jeffrey Barish |
|
From: Dan G. <dkg...@lb...> - 2008-05-09 11:44:05
|
being new to the list, I was looking at the archives and came across this post on Nov. 2007. If this is still an open question, an easy answer is: look at how TurboGears uses configobj to do exactly this! > When I needed a way to specify configuration parameters for my program, I > chose ConfigObj without looking closely at ConfigParser very closely > because > I had a feeling ConfigObj was better. Recently, I started using the > logging > package with my software. It allows me to specify its configuration > using a > configuration file, but it uses ConfigParser to access it. I would > like to > keep all configuration data in one configuration file, so I figured > that it > wouldn't be a big deal to switch my software over to ConfigParser. When I > first encountered get/set, my stomach twisted. When I discovered that I > couldn't specify a list as an option, I aborted. I was transforming code > that was simple and transparent into something verbose and opaque. > Because > my configuration file is not compatible with ConfigParser, I am > resigned to > two configuration files, one for my code and one for logging. However, > I am > wondering first whether I am missing a one-configuration-file solution. I > suppose that logging needs to be updated to use ConfigObj, but perhaps > I am > missing a solution that I can apply more readily. > -- > Jeffrey Barish -Dan -- Dan Gunter. voice:510-495-2504 fax:510-486-6363 dsd.lbl.gov/~dang |
|
From: Michael F. <fuz...@vo...> - 2008-05-09 11:57:18
|
Dan Gunter wrote: > being new to the list, I was looking at the archives and came across > this post on Nov. 2007. > > If this is still an open question, an easy answer is: look at how > TurboGears uses configobj to do exactly this! > I don't remember this email - thanks for the info! Michael Foord http://www.ironpythoninaction.com/ >> When I needed a way to specify configuration parameters for my program, I >> chose ConfigObj without looking closely at ConfigParser very closely >> because >> I had a feeling ConfigObj was better. Recently, I started using the >> logging >> package with my software. It allows me to specify its configuration >> using a >> configuration file, but it uses ConfigParser to access it. I would >> like to >> keep all configuration data in one configuration file, so I figured >> that it >> wouldn't be a big deal to switch my software over to ConfigParser. When I >> first encountered get/set, my stomach twisted. When I discovered that I >> couldn't specify a list as an option, I aborted. I was transforming code >> that was simple and transparent into something verbose and opaque. >> Because >> my configuration file is not compatible with ConfigParser, I am >> resigned to >> two configuration files, one for my code and one for logging. However, >> I am >> wondering first whether I am missing a one-configuration-file solution. I >> suppose that logging needs to be updated to use ConfigObj, but perhaps >> I am >> missing a solution that I can apply more readily. >> -- >> Jeffrey Barish >> > -Dan > > |
|
From: Michael F. <fuz...@vo...> - 2007-11-06 13:17:56
|
Jeffrey Barish wrote: > When I needed a way to specify configuration parameters for my program, I > chose ConfigObj without looking closely at ConfigParser very closely because > I had a feeling ConfigObj was better. Recently, I started using the logging > package with my software. It allows me to specify its configuration using a > configuration file, but it uses ConfigParser to access it. I would like to > keep all configuration data in one configuration file, so I figured that it > wouldn't be a big deal to switch my software over to ConfigParser. When I > first encountered get/set, my stomach twisted. When I discovered that I > couldn't specify a list as an option, I aborted. I was transforming code > that was simple and transparent into something verbose and opaque. Because > my configuration file is not compatible with ConfigParser, I am resigned to > two configuration files, one for my code and one for logging. However, I am > wondering first whether I am missing a one-configuration-file solution. I > suppose that logging needs to be updated to use ConfigObj, but perhaps I am > missing a solution that I can apply more readily. > I've not used the logging package - so I can't *really* comment. Is it not possible to swap out the configuration part of the logging package by supplying your config options programatically? That way you ccan write your own reading code that uses ConfigObj. Michael http://www.manning.com/foord |