David Thomas | 1 Nov 19:26 2012
Picon

Deriving settings from command line, environment, and files

Is there a library that provides a near-complete solution for this?
I looked around a bit and found many (many!) partial solutions on hackage,
but nothing that really does it all.  In coding it up for my own projects,
however, I can't help but feel like I must be reinventing the wheel.

What I want is something that will process command line options (this
seems to be where most packages are targetted), environment variables,
and settings files (possibly specified in options), and override/default
appropriately.

Did I miss something?

If not, I'd like to see about fixing the situation, but very much want
to avoid the whole "There were X libraries that didn't quite do it right;
now there's X+1!" thing.  Are there any opinions as to which of the many
libraries is likely the best starting point if I'm going to contribute
to one of them?








_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ben Gamari | 1 Nov 19:43 2012
Picon

Re: Deriving settings from command line, environment, and files

David Thomas <davidleothomas <at> gmail.com> writes:

> Is there a library that provides a near-complete solution for this?
> I looked around a bit and found many (many!) partial solutions on hackage,
> but nothing that really does it all.  In coding it up for my own projects,
> however, I can't help but feel like I must be reinventing the wheel.
>
> What I want is something that will process command line options (this
> seems to be where most packages are targetted), environment variables,
> and settings files (possibly specified in options), and override/default
> appropriately.
>
> Did I miss something?
>
Do you have an example of a library in another language that does what
you are looking for? boost's program_options library can handle
arguments read from a configuration file, but that's the closest example
I can come up with.

The design space for command line parsing libraries alone
is pretty large; when one adds in configuration file and environment
variable parsing, option overriding, and the like it's downright
massive. Moreover, programs vary widely in their configuration
requirements; it seems to me that it would be very difficult to hit a
point in this space which would be usable for a sufficiently large
number of programs to be worth the effort. This is just my two cents,
however.

If I were you, I'd look into building something on top of an existing
option parsing library. I think optparse-applicative is particularly
well suited to this since it nicely separates the definition of the
options from the data structure used to contain them and doesn't rely on
template haskell (unlike cmdargs). Composing this with configuration
file and environment variable parsing seems like it shouldn't be too
tough.

Cheers,

- Ben
Roman Cheplyaka | 1 Nov 20:10 2012

Re: Deriving settings from command line, environment, and files

* David Thomas <davidleothomas <at> gmail.com> [2012-11-01 11:26:01-0700]
> Is there a library that provides a near-complete solution for this?
> I looked around a bit and found many (many!) partial solutions on hackage,
> but nothing that really does it all.  In coding it up for my own projects,
> however, I can't help but feel like I must be reinventing the wheel.
> 
> What I want is something that will process command line options (this
> seems to be where most packages are targetted), environment variables,
> and settings files (possibly specified in options), and override/default
> appropriately.
> 
> Did I miss something?
> 
> If not, I'd like to see about fixing the situation, but very much want
> to avoid the whole "There were X libraries that didn't quite do it right;
> now there's X+1!" thing.  Are there any opinions as to which of the many
> libraries is likely the best starting point if I'm going to contribute
> to one of them?

What functionality would such a library provide?

There is a variety of good command-line parsing libraries and even more
possible configuration file formats. I don't think you want to commit to
some particular command-line syntax or config file format for the
library to be generally useful (and I don't see any benefit of doing
so).

But then the only part that remains is just combining the settings,
which is a simple monoidal operation. Just define the data type of your
settings, define/derive a Monoid instance for it in spirit of First/Last
monoids, and then mappend them in the right order.

(I also mostly concur with what Ben wrote on this subject.)

Roman

Gmane