New configuration module released - command line options
vinay_sajip at red-dove.com
Thu Nov 4 00:58:26 CET 2004
Neal Becker wrote:
> The point is, you would like to specify the options once, and use this
> single specification for all option sources - instead of redundantly having
> to specify that there is a 'verbosity' option that takes a value of 'int'
> and has a default of 'whatever', and do this once (and with different
> syntax) for each source - config files, command line, etc.
The optparse module is very good for parsing command line options, but
is not a general purpose program configuration facility. It's not really
sensible to grow optparse to become a general purpose program
The config module aspires to be a good configuration facility, but does
not concern itself with parsing command line options. There's little
point in reinventing the wheel when optparse is more than fit for
purpose, for many people.
Hence, the best option is to make them work together, but it's unlikely
that you'll get a 'one size fits all'. For example, some applications
will allow a user to specify which configuration to load via command
line options. In theory, a configuration file could be used to configure
command line options and you could call optparse with those. But it's
chicken and egg in many scenarios, and command line options for a
program tend to be less volatile than configurations in general. I think
it's more natural to specify configurations in a configuration file, and
allow overriding some subset of them via command-line arguments.
I've posted (in another post) an example of how config and optparse can
work together with minimal fuss.
More information about the Python-list