Expose an API for parsing Strings

[swfsql]

I once had an use-case where a String (instead of strictly a file/args) would need to be parsed.
Is it possible to expose an API for String parsing?

[ZoeyR]

I'm curious, what was the use-case you had where you had a String instead of a file?

[swfsql]

I was using structopt as well, which can get values from env vars, and I was setting the default values of such "env" vars with dotenv lol by including such "defaults" files and parsing their contents

So I'd parse from &str and I'd not necessarily push into the local env vars, id first get the parsed Hashmap of vars=value as well

[ZoeyR]

I didn't realize that structopt can fill in values from environment variables, interesting. If it can do that is there a reason that you did not run dotenv() to fill out your environment and then run structopt? That should have filled everything in right?

[swfsql]

Oh in some cases I preferred to read strings, I think it was for compile-time assertion.
The wrapping setup could also remove all env-vars at start (we also didn't enjoy using env vars directly from "within the code", everything env and config related would be setup early as a Config<> structure).

So we could use config files, command line args, env vars and .env files (multiple, recursive, etc), disable the env vars from the shell and also link to some default .env files as env vars at compile-time, as a default fallback (structopt read values as static strings as seen in TeXitoi/structopt#150 ).

We probably should just have stuck to config files and env vars, but oh well.. ^^

[albel727]

I'm curious, what was the use-case you had where you had a String instead of a file?
As for me, I need this, when I want to bake environment configuration into the program at compile time.

I'd use include_str!("../../.env") to get a &'static str with the compile time .env file contents, which I'd then parse at runtime with dotenv to set environment variables. I don't want to use dotenv! macro, because that robs me of the flexibility of being able to make my whole program depend on runtime environment again by changing just a couple of lines at the beginning of main().

In fact I may want to use both dotenv::dotenv() and parsing the baked-in .env string, to create environment variables at runtime -> .env file at runtime -> .env file at compile time chain of fallback.

[0xForerunner]

+1 I think this would be useful for unit tests!