Question

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.

Answer 1

"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.
- 
-