[Distutils] Config files working (I hope)

[Greg Ward]

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