Hi all -- I seem to have got the Distutils config file mechanism working. Please check out the latest code from the CVS archive (SourceForge!) and see how many bugs I left in. The basic idea is this: you can create 1 .. 3 config files, depending on your platform. On Unix: <prefix>/lib/python1.x/site-packages/distutils/pydistutils.cfg [1] $HOME/.pydistutils.cfg setup.cfg [1] this is really just the directory of the distutils package -- so it could be the distutils development directory if you haven't installed the distutils, or it could be lib/python1.6/distutils -- you get the idea. I'm not entirely thrilled with putting a config file in the library directory, but I was even less thrilled with any of the alternatives. ;-( On Windows and Mac OS: <prefix>/pydistutils.cfg setup.cfg Config files are read in the order listed above, ie. setup.cfg in the current directory takes precedence over ~/.pydistutils.cfg, which take precedence over the system pydistutils.cfg. Config files are in turn overridden by the command line. Syntax is as follows: [command] option=value ...as implemented by the standard ConfigParser module. Thus, [build] build_base=blib in setup.cfg is equivalent to python setup.py build --build-base=blib except, of course, that the config file is entirely passive: no commands are run based on what's found in the config file! Error-checking is done partly by the Distribution class and partly by the individual command classes. In particular, Distribution.get_command_obj() is responsible for ensuring that config files don't contain invalid options, ie. instance attributes not set in the command's 'initialize_options()' method. The command class itself is responsible for all other error-checking -- whether the content of an option is valid, whether certain options conflict, etc. This is the same mechanism as has worked for command-line options for ages now. There is a problem, though, which is that commands don't know *where* the options they are error-checking originate. The Distribution class keeps track of that information, in the 'command_options' dictionary, but it's currently not shared with the command classes. There are a couple of ways to do this, and I'm mulling the alternatives before diving in. Until that's fixed, you may get error messages that don't tell you if the offending option value was in a config file, on the command line, or what. Annoying but not fatal. Well, that's enough for tonight. Happy hacking! Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ The real Nazis run your schools / They're coaches, businessmen and cops -- Dead Kennedys