# argparse_config / argparse_config.src / README.rst

The argparse_config utility reads defaults for commandline args from a config file. The cute thing is, it figures out what config options to expect based on your argparse commandline args definition.

Let's say I'm reimplementing the Mercurial commandline client. I specify the commandline argument processing with argparse, of course:

arg_parser = ArgumentParser('hg')



When I go to use this client, though, I have to keep specifying my --user with every commit, and --tool with every merge. That sucks! What I want is to have my client understand a simple config file format:

[merge]
tool: meld

[commit]
user: Tikitu de Jager <tikitu@logophile.org>


And obviously, as I add more arguments and subcommands to my client, it should allow me to add defaults in the config file without writing more code.

This is what argparse_config gives you. To use it with the mercurial client arg_parser above:

>>> import argparse_config


... and that's it. Calling arg_parser.parse_args() will parse args as usual, but the default values will be taken from the config file, if they are given there:

>>> parsed_args = arg_parser.parse_args(['merge'])
>>> parsed_args.tool
'meld'


## 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.

## 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 things I plan to add:

• A utility to output a config file, based on a set of commandline arguments.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.