Make data and challenge directory configurable in config file

[kpcyrd]

Resolves #20

[alerque]

This looks good. As the subject for a possible future enhancement it might be worth looking at the config crate for handling this. I've had good luck with it paired with Clap for handling the logic of setting fallback from CLI args → runtime ENV vars → config files → defaults. It could be overkill for this usage, but the current manual handling of merge logic individually for relevant args vs. TOML keys and so forth is bound to eventually be brittle and/or repetitive.

[kpcyrd]

Thanks, I've been looking for something like that for some other projects too!

This seems to be working fine (and I ran into a bug with acme_email and acme_url not actually being read from the config file). Do you have any suggestions if I could write the structopt integration differently?

[alerque]

I've never worked directly with structopt, when I started learning Rust I went straight for clap, but they are pretty similar for this usage.

You can see one implementation I did with a set of Clap CLI definitions here, an internal runtime config manager here, and finally the binary here where the order of conf priority is actually accomplished.

Confusingly in that implementation I started out rolling my own, then later introduced config-rs. As a result CONFIG is basically my old implementation acting as a wrapper around Config. It would probably be easier to completely eliminate the wrapper and use Config directly, although the way I have it setup it then later doubles as a runtime key/value store that is usable across threads. That probably should be implemented separately from config data, but is implemented as another priority level on top of it.