Recognize `.env` for config in dev/testing

[fibonacci1729]

[radu-matei]

@fibonacci1729 — would you mind expanding a bit on the context for this issue?

Thanks!

[fibonacci1729]

When developing / running a Spin application, it would be convenient to source a .env file to construct the environment constants that will be made available to the application through the environment configuration provider.

For example, in the directory containing a Spin application:

some-app/
  ...
  .env
  spin.toml

Where some-app/.env contains:

FOO="BAR"

FOO will made available to the application through the SDK, e.g.

let val = spin_sdk::config::get("FOO")?;
assert_eq!(val, "BAR".to_string());

[radu-matei]

Are these variables that you don't want to set in spin.toml (which might be in source control)?

[fibonacci1729]

Yep, that is correct.

[fibonacci1729]

Unassigning myself for now as i'm not actively working on this just yet and don't want to issue squat.

[FrankYang0529]

Hi @fibonacci1729 , for this feature, is it about adding a dotenv provider? Or any config from .env can take priority over providers so that we can check it in get_config function before calling self.resolver.resolve?

[fibonacci1729]

@FrankYang0529 I think this can be as simple as:

If .env relative to spin.toml exists then source it

[fibonacci1729]

@FrankYang0529 would you be interested in #661 instead? It's slightly more involved (you get to implement a config provider) but still reasonably simple.

[FrankYang0529]

@fibonacci1729 actually, I would like to take these two. If it's okay, feel free to assign them to me. 😆

I have another question for .env. If there is a variable in .env but not defined in spin.toml, do we allow users to get the value?

[fibonacci1729]

Great question! We wouldn't want to allow getting the value if it's not defined in spin.toml.