views:

476

answers:

2

When your application takes a few (~ 5) configuration parameters, and the application is going to be used by non-technology users (i.e. KISS), how do you usually handle reading configuration options, and then passing around the parameters between objects/functions (multiple modules)?

Options examples: input and output directories/file names, verbosity level.

I generally use optparse (Python) and pass around the options/parameters as arguments; but I'm wondering if it's more common to use a configuration text file that is read directly by all modules' objects (but then, isn't this like having 'global' variables?, and without anyone 'owning' the state?).

Another typical issue is unit testing; if I want to unit test each single module independently, a particular module may only require 1 out of the 5 configuration options; how do you usually decouple individual modules/objects from the rest of the application, and yet still allow it to accept 1 or 2 required parameters (does the unit test framework somehow invoke or take over the configuration functionality)?

My guess is that there is not a unique correct way to do this, but it'd be interesting to read about various approaches, or well-known patterns.

A: 
"Counts answer"
Please update these counts and feel free to add/modify.

Do you usually read config options via:
- command-line/gui options : 1
- a config text file       : 0


How do multiple modules/objects have access to these options?
- they receive them from the caller as an argument: 1
- read them directly from the config text file:     0


When doing unit-testing of a single module (NOT the "main" module)
and the module uses one option, e.g. input filename:
- unit-test framework provides own "simplified" config functionality: 0
- unit-test framework invokes main app's config functionality:        1


Do you use:
- optparse:  1
- getopt:    0
- others?


Please list any config management "design pattern" 
(usable in Python) and add a count if you use it - thanks.
- 
-
jd
+2  A: 

Do you usually read config options via: - command-line/gui options - a config text file

Both. We use Django's settings.py and logging.ini. We also use command-line options and arguments for the options that change most frequently.

How do multiple modules/objects have access to these options?

  • settings.py; logging.ini -- can't say.
  • Our options are private to the main program, and used to build
    arguments to functions or object initializers.

[Sharing the optparse options is a big pain in the neck and needless binds a lot of things into an untestable mess.]

When doing unit-testing of a single module (NOT the "main" module): (e.g. read option specifying input filename)

[I can't parse the question. I assume this is "how do you test when there are options?"]

The answer is -- we don't. Since only the main method parses command-line options, no other module, function or class has any idea of command-line options. There's no this module "require 1 out of the 5 config options" The module's classes (or functions) have ordinary arguments and that's that.

We only use optparse.

S.Lott