What can I put in the config file?

Under the hood argparse_config uses the standard library ConfigParser. Arguments that aren’t for a subcommand go in the section [default]. The names are munged from the commandline argument, removing leading dashes and converting internal dashes to underscores (e.g. --log-level becomes log_level:).

Flags (i.e. commandline args that take no parameters) are turned on if present in the config, just like the commandline:

[default]
verbose

is the equivalent of --verbose. Either verbose: or verbose will work, but (watch out!) verbose: a-value doesn’t do anything different to verbose.

Writing a config file from some commandline arguments

Included in the package is a utility to generate a config file following these rules, from a given set of commandline arguments. The easy way to use it is to let it add a command to your args parsing:

>>> config_parser = get_config_parser('/home/tikitu/.my_hg.cfg')
>>> add_config_block_subcommand(arg_parser, sub_parsers, config_parser=config_parser)

and use it on the commandline:

$ hg.py config default --repository ssh://hg@bitbucket.org/tikitu/argparse_config > new_config.rc
$ hg.py config commit --username 'Tikitu de Jager <tikitu@logophile.org>' >> new_config.rc
$ cat new_config.rc
[default]
repository: ssh://hg@bitbucket.org/tikitu/argparse_config
[commit]
username: Tikitu de Jager <tikitu@logophile.org>

You can also use it programatically, if you like. That looks like this:

>>> parsed_args = arg_parser.parse_args(['--repository', 'https://bitbucket.org/tikitu/argparse_config', 'merge'])
>>> print argparse_config.generate_config(arg_parser, parsed_args, section='default', only_non_defaults=True)
[default]
repository: https://bitbucket.org/tikitu/argparse_config

Some complications make this less useful than it could be, sadly:

• If you use subcommands, you can only parse the args for one of them at a time (use the section argument to specify which, or leave it off to get the [default] section).

• We can’t tell the difference between default values written in code (which should not be added to the config file) and written in a previously-read-in config file (which should). This is why only_non_defaults exists.

How does it work?

By gudgeling about in the private internals of argparse. Yes, that’s not pretty.

Gotchas

Any required arguments that are present in a config file will show as optional, not required, in the --help output. (This is a bug-by-design, due to not having any clever idea about how to do it better.) It may help to tell yourself, “It’s not required on the commandline because I gave it in the config file.” (I will gladly make this dodgy rationalisation disappear if I figure out how to handle required arguments more tidily.)

Hacking

It’s on BitBucket. Feel free to play. It comes with a handy zc.buildout wrapper too, overkill though that clearly is.

TODO

It’s “alpha software” at present; likely to be buggy and lots of stuff ain’t there yet. Check the issues list to stay up to date. Some remaining open issues:

• How to deal with multi-value args? (The config-file library this is built on doesn’t support them.)

• The “write me a config file” support is scrappy. Can we do better?