Read options from Environment variables

[Iristyle]

Looks like you might have the best command line parser for .NET.

The one thing I see missing however (and maybe I just overlooked it), is the ability to map command line switches to environment variables.

If you have decoupled build from deployment, with a tool like Capistrano and intend to run with a Procfile on Linux (in our case, exported to Upstart), then it's pretty standard to config the application via environment variables. So rather than pass options through command line or .config files... we export some environment variables during deployment.

Have you given this any thought? It would be very useful to us.

Thanks!

[gsscoder]

@Iristyle, very glad this library save time to developers and you've joined the party! :))

If you look to issues, I'm always open to enhancement and/or any type of discussion.
This looks like a very interesting proposal.
I'm in final phases of release of the next stable; so enhancement will came on next beta (few days).

To get the point: you want as source of arguments, instead of Main(string[]), a list of environment variables?

Thanks for posting,
Giacomo

[Iristyle]

So looking at your example

class Options {
  [Option('r', "read", Required = true,
    HelpText = "Input file to be processed.")]
  public string InputFile { get; set; }

 // <snip />
}

Would become something like

class Options {
  [Option('r', "read", Environment = "INPUT_FILE", Required = true,
    HelpText = "Input file to be processed.")]
  public string InputFile { get; set; }

 // <snip />
}

Mono does something similar to this already with its ConfigurationManager format. For example, here's how the code for FastCgi is done.

https://github.com/mono/xsp/blob/master/src/Mono.WebServer.FastCgi/ConfigurationManager.xml

Does that all make sense?

[gsscoder]

Interesting...

You want the content of $INPUT_FILE to be set as default, if the user do not provide it via command line.

Is this?

[nemec]

@Iristyle your situation seems to be diverging from the purpose of "command line parsing". If I'm understanding you correctly, you want to map $PYTHON_HOME to Options.PythonHome (as opposed to parsing a command line string located in an environment variable)?

And you'd like to be able to combine both command line arguments and environment variables into a single Options object?

I had a similar need (specifically, command line + config) and built SmartConf. Essentially, it merges settings from multiple sources together into one master Config object.

Keeping to the philosophy of "do one thing and do it well", I believe that letting a ConfigurationManager manage multiple configuration sources is better than turning a command line parser into something that tries to parse arguments from elsewhere too.

You would have to write your own source for parsing environment variables (I'd be happy to accept a pull request), but I wrote my own source for this CommandLine library that you can use here.

Sorry for the shameless plug, but I wrote SmartConf pretty much exactly for situations like this :)

[gsscoder]

@nemec,
you're quoting the Single-Responsibility principle of SOLID?

[gsscoder]

One of the founding principles of this library was to group same common command line usage pattern and group into to single project.

What say @nemec is 100% correct from a design perspective.

Anyway if you need advanced command line parsing you won't rely on a bare-bone library, you search a specialized one.

A specialized one can capture a common capture and let users read defaults from different sources.

We can also keep also play with semantic calling it EnvironmentDefaultValue causing the library to throw an exception if you use both, or use ÐefaultValue if the environment can't be read or is empty.

We can also start implementing an internal syntax in DefaultValue:

class Options {
  [Option('r', "read", DefaultValue = "environment:INPUT_FILE", Required = true,
    HelpText = "Input file to be processed.")]
  public string InputFile { get; set; }

 // <snip />
}

Internal we can create providers registred by the prefix string, for example and let developers write their owns.

E.g. @nemec can write it's own enabling:

DefaultValue = "smartconf:A_SMARTCONF_HANDLE_VALUE"

I'm not talking of class hierarchies instead something based on standard delegates (Action etc).

It's also not difficult if someone need an input with semantic, we can find a character that internally force a verbatim string like C# compiler does.

These are only first toughs... :))

[nemec]

@gsscoder I was thinking more of the UNIX philosophy, but I believe the Single-Responsibility principle is applicable here too.

Smartconf already does what you're suggesting, but in reverse. Each "source" is a configuration provider, one of which is a wrapper around your CommandLineParser. It calls the parsing code, then merges any properties that were modified by the parser into the "master" config object.

Note that your suggestion of using strings for service registration works, but it makes providing specific parameters to each provider (like a custom config file) more complicated.

[gsscoder]

@nemec, why you not said me of this new enhancements? We should list is a friend library? Am I wrong?

[gsscoder]

Btw. @Iristyle , @nemec,
in Windows we also also the problem to target the env variable
http://msdn.microsoft.com/en-us/library/system.environmentvariabletarget.aspx

Nothing similar happens in *nix. Right?

[nemec]

Sure, that would work. Here's a direct link to the project with an example. I don't think any *nix OS has an environment variable target, it all depends on which user you're running under.

[gsscoder]

As you probably know if you watch the repo, @Iristyle, I'm currently working on the new beta (https://github.com/gsscoder/commandline/tree/develop-1.9.8-beta).

From now to few days I'll ready to implement enh like this.

I'd like to know your final thoughts after @nemec illustrated the alternate possibility.

Others users requested something similar by other channels, so I really like to know what do you think.

Since the issue its open, I assume you're still interested in viewing such thing in commandline.

:)) have nice day - @gsscoder

[Iristyle]

@gsscoder sorry I've been a bit absent, but thanks for your responses.

I do agree with @nemec that command line parsing and environment variable parsing are two mechanisms for grabbing configuration data (with *.config / xml being the third major one in the .NET world), and keeping inline with the unix philosophy, maybe it's not so good to shoehorn reading of environment variables from your commandline parser.

If we look at Nodes optparse it follows the same Unix philosophy. It does commandline parsing, and that's it.

I don't see the environment variable parsing bits in SmartConf @nemec ... do you have an example?

[nemec]

@Iristyle That source does not exist. You're welcome to set one up and send a pull request, but I'll see if I have some time this weekend to look into adding it.

[gsscoder]

@Iristyle, there's absolutely no problem! :)) Reply as more as more convenient with your commitments.

So @Iristyle you're opinion is aligned with @nemec? Should we keep this feature, out of the library as nodejs module quoted?

[Iristyle]

Yeah, I think @nemec is right here, given your library is aimed squarely at command line parsing and not configuration management.

The composition of the two probably belongs in something like SmartConf...