Import and execfile()

[George Sakkis]

I maintain a few configuration files in Python syntax (mainly nested
dicts of ints and strings) and use execfile() to read them back to
Python. This has been working great; it combines the convenience of
pickle with the readability of Python. So far each configuration is
contained in a single standalone file; different configurations are
completely separate files.

Now I'd like to factor out the commonalities of the different
configurations in a master config and specify only the necessary
modifications and additions in each concrete config file. I tried the
simplest thing that could possibly work:

======================
# some_config.py

# master_config.py is in the same directory as some_config.py
from master_config import *

# override non-default options
foo['bar']['baz] = 1
....

======================
# trying to set the configuration:
CFG = {}
execfile('path/to/some_config.py', CFG)

Traceback (most recent call last):
....
ImportError: No module named master_config


I understand why this fails but I'm not sure how to tell execfile() to
set the path accordingly. Any ideas ?

George

 

[Mike Meyer]

I maintain a few configuration files in Python syntax (mainly nested
dicts of ints and strings) and use execfile() to read them back to
Python. This has been working great; it combines the convenience of
pickle with the readability of Python. So far each configuration is
contained in a single standalone file; different configurations are
completely separate files.

You know, I've been there before. It's kinda neat, but not something
you really want to put in the hands of most users.

You can make the syntax cleaner by using classes to hold the values
instead of nested dicts, etc. That way you don't have to quote the
names of the values:

class Foo:
bar = 1
baz = 2

The really slick part was that if the config classes line up with the
implementation classes, you can create an instance of the config class
for the implementation object, and it can then change those values to
change it's behavior without changing the defaults other instances
see.

Now I'd like to factor out the commonalities of the different
configurations in a master config and specify only the necessary
modifications and additions in each concrete config file. I tried the
simplest thing that could possibly work:

With classes you factor out the commonality by factoring it into a
base class that the others inherit from.

======================
# some_config.py

# master_config.py is in the same directory as some_config.py
from master_config import *

# override non-default options
foo['bar']['baz] = 1
...

======================
# trying to set the configuration:
CFG = {}
execfile('path/to/some_config.py', CFG)

Traceback (most recent call last):
...
ImportError: No module named master_config


I understand why this fails but I'm not sure how to tell execfile() to
set the path accordingly. Any ideas ?

Manipulate sys.path yourself?

<mike

 

[Mitko Haralanov]

# trying to set the configuration:
CFG = {}
execfile('path/to/some_config.py', CFG)

Traceback (most recent call last):
...
ImportError: No module named master_config


I understand why this fails but I'm not sure how to tell execfile() to
set the path accordingly. Any ideas ?

This might be overly simplistic but you could have a load_config
function which takes the path to the config file and the variable where
to load the config as arguments.

In the load_config function, you could get the directory part of the
config file path, appending it to sys.path, load the config, and then
remove the newly added directory from sys.path.

 

[George Sakkis]

You know, I've been there before. It's kinda neat, but not something
you really want to put in the hands of most users.

Well, I am almost the only user (of the config file, not the
application) and the few others are developers too so that's not an
issue in this case.

You can make the syntax cleaner by using classes to hold the values
instead of nested dicts, etc. That way you don't have to quote the
names of the values:

class Foo:
bar = 1
baz = 2

Actually I am using the dict() constructor instead of literals so it's
as clean as with classes; IMO for nested options it's cleaner than
nested classes:

Env = dict(
PORT = 6789,
KEY = 123456789,
EXE = '/usr/local/lib/myprog',
LD_LIBRARY_PATH = ':'.join([
'/usr/lib',
'/usr/local/lib',
]),
OPTIONS = dict(
n = None,
min = 1,
max = 15000,
)
)

======================
# some_config.py

# master_config.py is in the same directory as some_config.py
from master_config import *

# override non-default options
foo['bar']['baz] = 1
...

======================
# trying to set the configuration:
CFG = {}
execfile('path/to/some_config.py', CFG)

Traceback (most recent call last):
...
ImportError: No module named master_config

I understand why this fails but I'm not sure how to tell execfile() to
set the path accordingly. Any ideas ?

Manipulate sys.path yourself?

That's what Mitko suggested too, and indeed it works:

import sys, os

def setConfig(configfile):
cfg = {}
syspath = list(sys.path)
try:
sys.path.append(os.path.dirname(configfile))
execfile(configfile, cfg)
finally:
sys.path = syspath
return cfg


However this doesn't look very clean to me. Also it's not thread-safe;
guarding it explicitly with a lock would make it even less clean.
Ideally, I'd like to pass a new path to execfile without modifying the
original (even for the few milliseconds that execfile() wlll probably
take). With modules being singletons though, I don't think this is
possible, or is it ?

George

 

[George Sakkis]

This might be overly simplistic but you could have a load_config
function which takes the path to the config file and the variable where
to load the config as arguments.

In the load_config function, you could get the directory part of the
config file path, appending it to sys.path, load the config, and then
remove the newly added directory from sys.path.

Thanks, that's basically what I did eventually and it works for my
simple requirements. Another alternative would be to require the
config files to be modules already in the path. In this case setConfig
becomes almost trivial using __import__ instead of execfile():

import inspect
def setConfig(configfile):
return dict(inspect.getmembers(__import__(configfile,
fromlist=True)))

On the downside, the config files cannot be moved around as easily as
with execfile. Also, if placed in directories that are not in the
path, one or more ancestor directories may have to be populated with
(empty) __init__.py files to denote them as Python packages. So
generally speaking, when should execfile be preferred to __import__,
or the other way around ?

George

 

[Mike Meyer]

Actually I am using the dict() constructor instead of literals so it's
as clean as with classes; IMO for nested options it's cleaner than
nested classes:

Yup, that does that. Wasn't available last time I did this, so...

That's what Mitko suggested too, and indeed it works:
However this doesn't look very clean to me. Also it's not thread-safe;

I don't know that there is a clean solutions. As for not being
thread-safe, I'd suggest that you should have all your configuration
information loaded *before* you start any threads. This makes shutting
down in case you decide there's something wrong in it easier, and in
some cases may prevent inadvertently doing things that shouldn't
oughta be done. In the case where you config files are parsed by the
python interpreter, this goes double because a busted config file
could lead to exceptions, leaving your application in an unknown
state.

<mike