Configuration loading

[killercup]

In #19 (comment), @moosingin3space suggested adding configure.

[killercup]

• Does this work with types that also derive structopt in a nice way?
• Are people using env vars to configure their CLI apps?

[polarathene]

I've written some CLI apps that if they have many config args and are used often with variety of values, have another arg to load in JSON config containing the args and values to use. It's quite staight forward to use for anyone I pass the tools on to.

I've also used Docker where images/containers use ENV vars for config, it supports having a .env file to apply ENV vars if you don't want to use system ones, also easier for some users to grasp/manage and portable. I've also written some containers myself that specify the ENV vars when run/built. I think some other tools like version managers for different language runtimes can use .env as well for configurability, same with node.js cli tools like npm, they'd all otherwise still use system ENV vars if no .env file is in the directory. In my bash profile on Linux I have ENV vars set too. I don't use them frequently, and I suppose that's the point :)

[yoshuawuyts]

Are people using env vars to configure their CLI apps?

I rarely do. The only time when this comes in handy is when needing to debug output of a nested dependency. Set a specific env var: get the exact debug output you're looking for.

However, I really dig the concept of a main.rs function consuming a bunch of Configuration structs from lib files, and then passes it into structopts' enum thingy to get subcommands. That allows a lot of the code to configure subcommands stay in the lib, without binding it to the CLI code at all. I like the idea of having bin code be a thin wrapper around lib code. Does that make sense?

It'd be neat if we could set flags from configure tho; I think a good check might be: "Could we reimplement git(1)'s interface using this approach."

[vbrandl]

While most CLI applications don't load their configuration from environment variables, configuration files are pretty common.
I think it would be cool to be able to load most of the configuration from a file (additionally, there should be a -c flag to change the default path to the configuration file) and set/override the rest using args.
An application could load a config file:

host = "127.0.0.1"
port = 8080

and passing --host or --port should overwrite the value in the config file.

Using feature flags, it should be pretty trivial to support different configuration formats using serde.

A second step would be a feature to dump a config file using the default values in the default config path on first run (e.g. if the config file does not exist)