Fwd: argparse - add support for environment variables

---------- Forwarded message ---------- From: Ian Cordasco <graffatcolmingov@gmail.com> Date: Tue, Feb 19, 2013 at 11:35 AM Subject: Re: [Python-ideas] argparse - add support for environment variables To: Miki Tebeka <miki.tebeka@gmail.com> Cc: python-ideas@googlegroups.com Why not: parser.add_argument('--spam', default=os.environ.get('SPAM', 7)) This way if SPAM isn't set, your default is 7. If spam is set, your default becomes that. On Tue, Feb 19, 2013 at 11:03 AM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
GMail decided to reply to python-ideas at googlegroups.com, but this was my response which I shamefully did not bottom post.

Why not:
parser.add_argument('--spam', default=os.environ.get('SPAM', 7))
Mainly because then you can't swap in different dictionaries to resolve SPAM (when specifying "env" to ArgumentParser). The other reason is that it's making common code shorter, which is a win IMO.

This is something I wanted before (as well as loading defaults from per user config files). A solution was proposed a while back, but it was never merged due to a lack of consensus on the API: http://code.google.com/p/argparse/issues/detail?id=35 Not sure if there is a more recent discussion. ________________________________________ From: Python-ideas [python-ideas-bounces+moloney=ohsu.edu@python.org] On Behalf Of Miki Tebeka [miki.tebeka@gmail.com] Sent: Tuesday, February 19, 2013 3:51 PM To: python-ideas@googlegroups.com Cc: python-ideas Subject: Re: [Python-ideas] Fwd: argparse - add support for environment variables Why not: parser.add_argument('--spam', default=os.environ.get('SPAM', 7)) Mainly because then you can't swap in different dictionaries to resolve SPAM (when specifying "env" to ArgumentParser). The other reason is that it's making common code shorter, which is a win IMO.

On Tue, Feb 19, 2013 at 3:51 PM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
Can you elaborate on this requirement?
The other reason is that it's making common code shorter, which is a win IMO.
How common is such code? YMMV here... I don't think it's nearly common enough to warrant adding complexity to a stdlib module in order to implement a non-orthogonal feature. In general, I'm -1 on the idea. argparse is for parsing command line arguments. Python provides you convenient access to env vars via os.environ. Why mix up the two? Eli

Eli Bendersky wrote:
well, command line arguments, environmental variables and, I add, configuration files are commonly intertwined. While argparse focus on the first one, there are cases where you want some "layer" on top of it and on os.environ and on... ConfigParser?) to DRY. -- ZeD

On 20 February 2013 06:59, Vito De Tullio <vito.detullio@gmail.com> wrote:
configglue combines support for config files (and hierarchies of config files) with command line arguments. https://pypi.python.org/pypi/configglue/ Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Michael Foord <fuzzyman@...> writes:
configglue combines support for config files (and hierarchies of config files)
with command line arguments.
So does the config module: http://www.red-dove.com/config-doc/ Regards, Vinay Sajip

On Tuesday, February 19, 2013 8:29:48 PM UTC-8, Eli Bendersky wrote:
Sure. The idea is the you have some kind of "parameter resolution" (very much like the interpreter is resolving variables). You first look into the command line, and if not found you query a dictionary. Most times, this dictionary will be os.environ. However you can pass your own dictionary to resolve the parameters (for testing, configuration files). You can even use something like Raymonds Nested Contexts<http://code.activestate.com/recipes/577434-nested-contexts-a-chain-of-mapping-objects/>for that matter.

On Wed, Feb 20, 2013 at 10:10 AM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
What about config files? Mix them into argparse too? Oh, and support for .ini/XML/YAML/JSON/sqlite configs, please! Sarcasm aside (don't take it personally ;-), my point is this: argparse is a nice, orthogonal library for dealing with command-line arguments. Let's keep it this way. Python gives you tools to *very easily* mix up different configuration paths, with really minimal effort. Eli

On Thu, Feb 21, 2013 at 10:18 AM, Eli Bendersky <eliben@gmail.com> wrote:
Indeed - a layered architecture is the way to go here. argparse can be a *component* of a comprehensive configuration system, but it shouldn't try to *become* a comprehensive configuration system. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Thursday 21 Feb 2013, Miki Tebeka wrote:
In the interests of doing it the UNIX way, would this be better done as a parser for the .ini/XML/YAML (they're ALL YAML, though. Yet ANOTHER Meta Language..!) that results in $ENV changing in python. Send the result that to argparse. Bada-bum, bada-bing, done.

On Tue, Feb 19, 2013 at 3:51 PM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
Couldn't you achieve this with a simple helper function? Something along the lines of-- env = {'SPAM': 9} parser = argparse.ArgumentParser() def add_argument(key, *args, **kwargs): if key in env: kwargs['default'] = env[key] parser.add_argument(*args, **kwargs) add_argument('SPAM', '--spam', default=7) ... This also allows env to be an arbitrary dictionary. --Chris

Why not:
parser.add_argument('--spam', default=os.environ.get('SPAM', 7))
Mainly because then you can't swap in different dictionaries to resolve SPAM (when specifying "env" to ArgumentParser). The other reason is that it's making common code shorter, which is a win IMO.

This is something I wanted before (as well as loading defaults from per user config files). A solution was proposed a while back, but it was never merged due to a lack of consensus on the API: http://code.google.com/p/argparse/issues/detail?id=35 Not sure if there is a more recent discussion. ________________________________________ From: Python-ideas [python-ideas-bounces+moloney=ohsu.edu@python.org] On Behalf Of Miki Tebeka [miki.tebeka@gmail.com] Sent: Tuesday, February 19, 2013 3:51 PM To: python-ideas@googlegroups.com Cc: python-ideas Subject: Re: [Python-ideas] Fwd: argparse - add support for environment variables Why not: parser.add_argument('--spam', default=os.environ.get('SPAM', 7)) Mainly because then you can't swap in different dictionaries to resolve SPAM (when specifying "env" to ArgumentParser). The other reason is that it's making common code shorter, which is a win IMO.

On Tue, Feb 19, 2013 at 3:51 PM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
Can you elaborate on this requirement?
The other reason is that it's making common code shorter, which is a win IMO.
How common is such code? YMMV here... I don't think it's nearly common enough to warrant adding complexity to a stdlib module in order to implement a non-orthogonal feature. In general, I'm -1 on the idea. argparse is for parsing command line arguments. Python provides you convenient access to env vars via os.environ. Why mix up the two? Eli

Eli Bendersky wrote:
well, command line arguments, environmental variables and, I add, configuration files are commonly intertwined. While argparse focus on the first one, there are cases where you want some "layer" on top of it and on os.environ and on... ConfigParser?) to DRY. -- ZeD

On 20 February 2013 06:59, Vito De Tullio <vito.detullio@gmail.com> wrote:
configglue combines support for config files (and hierarchies of config files) with command line arguments. https://pypi.python.org/pypi/configglue/ Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Michael Foord <fuzzyman@...> writes:
configglue combines support for config files (and hierarchies of config files)
with command line arguments.
So does the config module: http://www.red-dove.com/config-doc/ Regards, Vinay Sajip

On Tuesday, February 19, 2013 8:29:48 PM UTC-8, Eli Bendersky wrote:
Sure. The idea is the you have some kind of "parameter resolution" (very much like the interpreter is resolving variables). You first look into the command line, and if not found you query a dictionary. Most times, this dictionary will be os.environ. However you can pass your own dictionary to resolve the parameters (for testing, configuration files). You can even use something like Raymonds Nested Contexts<http://code.activestate.com/recipes/577434-nested-contexts-a-chain-of-mapping-objects/>for that matter.

On Wed, Feb 20, 2013 at 10:10 AM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
What about config files? Mix them into argparse too? Oh, and support for .ini/XML/YAML/JSON/sqlite configs, please! Sarcasm aside (don't take it personally ;-), my point is this: argparse is a nice, orthogonal library for dealing with command-line arguments. Let's keep it this way. Python gives you tools to *very easily* mix up different configuration paths, with really minimal effort. Eli

On Thu, Feb 21, 2013 at 10:18 AM, Eli Bendersky <eliben@gmail.com> wrote:
Indeed - a layered architecture is the way to go here. argparse can be a *component* of a comprehensive configuration system, but it shouldn't try to *become* a comprehensive configuration system. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Thursday 21 Feb 2013, Miki Tebeka wrote:
In the interests of doing it the UNIX way, would this be better done as a parser for the .ini/XML/YAML (they're ALL YAML, though. Yet ANOTHER Meta Language..!) that results in $ENV changing in python. Send the result that to argparse. Bada-bum, bada-bing, done.

On Tue, Feb 19, 2013 at 3:51 PM, Miki Tebeka <miki.tebeka@gmail.com> wrote:
Couldn't you achieve this with a simple helper function? Something along the lines of-- env = {'SPAM': 9} parser = argparse.ArgumentParser() def add_argument(key, *args, **kwargs): if key in env: kwargs['default'] = env[key] parser.add_argument(*args, **kwargs) add_argument('SPAM', '--spam', default=7) ... This also allows env to be an arbitrary dictionary. --Chris
participants (11)
-
Brendan Moloney
-
Chris Jerdonek
-
Eli Bendersky
-
Ian Cordasco
-
Mark Hackett
-
Michael Foord
-
Miki Tebeka
-
Nick Coghlan
-
Vinay Sajip
-
Vito De Tullio
-
Yuval Greenfield