unified command line args, environment variables, .conf filesettings.

S

smitty1e

Just a fun exercise to unify some of the major input methods for a
script into a single dictionary.
Here is the output, given a gr.conf file in the same directory with
the contents stated below:

smitty@localhost ~/proj/mddl4/test $ ./inputs.py
{'source_db': '/home/sweet/home.db'}
smitty@localhost ~/proj/mddl4/test $ source_db="test_env" ./inputs.py
{'source_db': 'test_env'}
smitty@localhost ~/proj/mddl4/test $ ./inputs.py -f "test_cli"
{'source_db': 'test_cli'}


For the file
=========
#!/usr/bin/env python

#Goal: unification of environment variables, command line, and
# configuration file settings.
# The .conf file is the specification.
# Optional environment variables can override.
# Optional command-line inputs trump all.
# Example is a file spec for a source database for an application.
# .conf has a contents like:
#================================
# [CONF]
# source_db=/home/sweet/home.db

#TODO:
# 1. Decide (make an option?) to retain the simple dictionary or build
a
# class from the options.
# 2. Allow for multiple .conf locations, trying to be cool like
# xorg.conf

from ConfigParser import SafeConfigParser
from optparse import OptionParser
import os

CONF = "CONF" #section in .conf file
CONF_FILE = "gr.conf" #name of config file
PLACEBO = "placebo" #mindless default that we don't want
gconf = {} #all your config are belong to here
parser = OptionParser()
parser.add_option( "-f" , "--file"
, dest = "source_db"
, help = "source database"
, default = PLACEBO )
(cl_opts, args) = parser.parse_args()

config = SafeConfigParser()
config.read(CONF_FILE)
file_conf = dict(config.items(CONF))

for k in file_conf:

gconf[k]=file_conf[k]

if os.environ.has_key(k):
gconf[k] = os.environ[k]

if cl_opts.__dict__.has_key(k):
if cl_opts.__dict__[k]!=PLACEBO:
gconf[k] = cl_opts.__dict__[k]
print gconf
 
S

smitty1e

smitty1e said:
Just a fun exercise to unify some of the major input methods for a
script into a single dictionary.
Here is the output, given a gr.conf file in the same directory with
the contents stated below:
smitty@localhost ~/proj/mddl4/test $ ./inputs.py
{'source_db': '/home/sweet/home.db'}
smitty@localhost ~/proj/mddl4/test $ source_db="test_env" ./inputs.py
{'source_db': 'test_env'}
smitty@localhost ~/proj/mddl4/test $ ./inputs.py -f "test_cli"
{'source_db': 'test_cli'}

A good start. However, you need to account for two conventions with
configuration of programs via environment variables:
[snip]
This is probably best done by a mapping specifically for the
environment variable names:

config_env_names = {
'source_db': 'GR_SOURCE_DB',
}

and then referencing that dictionary when inspecting the environment:

for key in config.keys():
# ...
environ_name = config_env_names[key]
environ_value = os.environ.get(environ_name)
if environ_value is not None:
config[key] = environ_value
#...

Hmmm...
I kinda think your excellent points are more in the realm of policy
than mechanism.
What I was going for was to assert that there a designated section (of
many possible ones)
in a .conf file that represents the set of possible program inputs,
and then
offering an example of letting environment and command line arguments
override that
..conf section.
Your points for reducing collision are well taken. Possibly having a
removable prefix
(which could be a "magic" .conf entry) would allow for a de-conflictor
prefix like
MY_PROGRAM_REALLY_ROCKSsource_db without having to propagate such an
eyesore throughout
the program code.
In any case, it stands as a fun little worked example.
R,
C
 
A

andrej.panjkov

Just a fun exercise to unify some of the major input methods for a
script into a single dictionary.
Here is the output, given a gr.conf file in the same directory with
the contents stated below:


How about extending this to include other sources of control inputs.
I think a reasonable heirarchy is:

Interactive Input
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top