argparse - add support for environment variables
Greetings, The usual way of resolving configuration is command line -> environment -> default. Currently argparse supports only command line -> default, I'd like to suggest an optional "env" keyword to add_argument that will also resolve from environment. (And also optional env dictionary to the ArgumentParser __init__ method [or to parse_args], which will default to os.environ). Example: [spam.py] parser = ArgumentParser() parser.add_argument('--spam', env='SPAM', default=7) args = parser.parse_args() print(args.spam) ./spam.py -> 7 ./spam.py --spam=12 -> 12 SPAM=9 ./spam.py -> 9 SPAM=9 ./spam.py --spam=12 -> 12 What do you think? -- Miki
OK, so what's next in process? Got some +1 and some -1, how do we proceed? (or not). On Tuesday, February 19, 2013 8:03:16 AM UTC-8, Miki Tebeka wrote:
Greetings,
The usual way of resolving configuration is command line -> environment -> default. Currently argparse supports only command line -> default, I'd like to suggest an optional "env" keyword to add_argument that will also resolve from environment. (And also optional env dictionary to the ArgumentParser __init__ method [or to parse_args], which will default to os.environ).
Example: [spam.py]
parser = ArgumentParser()
parser.add_argument('--spam', env='SPAM', default=7) args = parser.parse_args() print(args.spam)
./spam.py -> 7 ./spam.py --spam=12 -> 12 SPAM=9 ./spam.py -> 9 SPAM=9 ./spam.py --spam=12 -> 12
What do you think? -- Miki
On 3/18/2013 7:02 PM, Miki Tebeka wrote:
OK, so what's next in process? Got some +1 and some -1, how do we proceed? (or not).
Seems not.
On Tuesday, February 19, 2013 8:03:16 AM UTC-8, Miki Tebeka wrote:
Greetings,
The usual way of resolving configuration is command line -> environment -> default. Currently argparse supports only command line -> default, I'd like to suggest an optional "env" keyword to add_argument that will also resolve from environment. (And also optional env dictionary to the ArgumentParser __init__ method [or to parse_args], which will default to os.environ).
Example: [spam.py]
from os import environ as env
parser = ArgumentParser()
parser.add_argument('--spam', env='SPAM', default=7)
parser.add_argument('--spam', default = env.get('SPAM', 7)) This is about the same number of chars to type and I believe it is available now in all versions. I like it better because it puts the e.v. name and default right together. -- Terry Jan Reedy
Here's an idea. We have 4 main sources of config: 1. app defaults 2. config file 3. env var 4. command line Instead of adding anything to the code for each of these parsers, suppose that each of them accepted a dictionary of options in a common form, so that they could be composed easily. For example, suppose we call config file parser 1st, and it returns a dict of what items are set in the config file (not the defaults). Then argparse is called (without using and defaults), passing it that dictionary, which it can add to or overide. Finally, options not in the dict get defaults applied. Having not dug into technical details, I'm imagining that either arparse already can accept a dict or options, or could be easily modified to. Or, we simply call argparse normally, then take it's dict and we merge the dicts outside of arparse.
IMO one env which is a ChainMap ( http://docs.python.org/dev/library/collections#collections.ChainMap) will be enough. This will give you more flexibility and you'll be able to chain more "environments" if needed. On Wednesday, March 27, 2013 8:47:45 AM UTC-7, Neal Becker wrote:
Here's an idea. We have 4 main sources of config:
1. app defaults 2. config file 3. env var 4. command line
Instead of adding anything to the code for each of these parsers, suppose that each of them accepted a dictionary of options in a common form, so that they could be composed easily.
For example, suppose we call config file parser 1st, and it returns a dict of what items are set in the config file (not the defaults). Then argparse is called (without using and defaults), passing it that dictionary, which it can add to or overide. Finally, options not in the dict get defaults applied.
Having not dug into technical details, I'm imagining that either arparse already can accept a dict or options, or could be easily modified to. Or, we simply call argparse normally, then take it's dict and we merge the dicts outside of arparse.
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/mailman/listinfo/python-ideas
participants (3)
-
Miki Tebeka -
Neal Becker -
Terry Reedy