Re: [Haskell-cafe] Deriving settings from command line, environment, and files
* David Thomas [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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deriving settings from command line, environment, and files
David Thomas 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
