Setting environment variables

[killercup]

Supporting setting/clearing of the environment variables.

AssertCli::command("echo $foo").with_env(es) where es is an IntoIter<Item=(&str, &str)>, e.g. &[("foo", "bar")]

cf. #21

[Freyskeyd]

I'm on it.

I need to be able to override environment variables for some tests.

You said setting/clearing of the environment variables, it means that with_env override completely all environment variables? Does it merge with the currently defined variables?

[killercup]

it means that with_env override completely all environment variables?

Yeah I think that's what past me was thinking 😅

std::env::vars returns this struct which is a Interator<Item=(String, String)>. So, inheriting some env vars and adding others is possible with some iterator chaining (cf. this playpen), but it's not very nice.

Do you have a suggestion how to make this a nice API?

---

From what I can tell, this feature probably doesn't block our next release (hopefully 1.0).

[epage]

When I was considering implementing this, I was thinking the API would look like

• env to add one variable to existing environment
• envs to add a series of variables to the existing environment
• with_env to set a new environment
  (basing the API off of std::prcoess::Command)

This allows the program under test to inherit an environment or get one from scratch, as well as add additional variables to it.

I imagine the Assert would contain

• clear_environ: bool
• envs: Vec<(OsStr, OsStr>

So the operations would have the following behavior

• env appends
• envs extends
• with_env sets clear_environ and clears envs

[Freyskeyd]

@epage I agree.

I was thinking of:

let test = assert_cli::Assert::command(&["some", "command"])
    .env("key", "value") // Just add one
    .envs(&[("key", "value")]) // Extends with multiple vars
    .with_env(&vars) // Clean and write new bunch of vars
    .remove("key") // Remove only one var
    .stdout().contains("42")
    .unwrap();

assert!(test.is_ok());

What do you think?
Do we need to provide a way to remove a bunch of vars? like .remove(&["key1", "key2"]) ?

[killercup]

(Oh, right, should be OsStr. Even though vars() returns (String, String) for some reason…)

Do you think it'd be a good idea to move this to its own small DSL so we only need to have with_env and can also cache and share env var settings between AssertCli calls? Something like

use assert_cli::{Assert, Env};

let vars: Env = Env::inherit().except(&["FOO", "BAR"]).add("FOO", "42");

Assert::command(&["whatever"])
.with_env(&vars)
.fails().unwrap();

Assert::command(&["whatever"])
.with_env(&vars.add("BAR", "1337"))
.contains("OK").unwrap();

[epage]

Do we need to provide a way to remove a bunch of vars? like .remove(&["key1", "key2"]) ?

Overall, my opinion is to model the API after Process. In that context its called env_remove and it only accepts one parameter

[Freyskeyd]

Why not. But I like the way we can add single (or more) variable without instantiate a new variable:

Assert::command(&["whatever"])
.with_env(&[("key", "value"), ("key2", "value")]) // inherit and set/override key and key2
.fails().unwrap();

let vars: Env = Env::inherit().except(&["FOO", "BAR"]).add("FOO", "42");

Assert::command(&["whatever"])
.with_env(&vars) // use the previously defined vars
.fails().unwrap();

One thing is possible. with_env can accept a ToEnv trait.

When passing a &[("key", "value")], we should be able to define an Env with inherit and override keys.

[killercup]

with_env can accept a ToEnv trait.

Good idea for a shortcut. Not sure about the defaulting to inherit, though. I think it'll be the most commonly used option, but the inherit is very implicit…

[epage]

Do you think it'd be a good idea to move this to its own small DSL so we only need to have with_env and can also cache and share env var settings between AssertCli calls? Something like

• That was the main alternative in my mind to my stdout API I wrote. The main reason I didn't do it is brevity.
• It is more like how clap does its fluent API.
• Reuse in tests is an interesting problem. It highlights even more the problem with over applying DRY because they tend towards more incidental code patterns (diverge with requirements) rather than inherent code patterns (shared requirements)

For me, personally, I don't yet have use cases enough to use environments to really say whether the API is best with reuse or not.

I would say that the API should not borrow so that someone can declare their environment inline

Assert::command(&["whatever"])
.with_env(Env::empty().add("FOO", "42"))
.fails().unwrap();

[epage]

Good idea for a shortcut. Not sure about the defaulting to inherit, though. I think it'll be the most commonly used option, but the inherit is very implicit…

btw with your separate DSL, I really liked the idea of calling it inherit