`main_binary` and `cargo_binary` fail with `Environment::empty`

[epage]

cargo can't be found because it is no longer in the path.

[epage]

I think this is a reasonable limitation, I just wanted to ensure it is noted somewhere.

So ways I see forward for this

• Rejecting it with label wontfix
• Noting the limitation somewhere (an example workaround?) and closing this out with that (maybe still with a label wontfix).

[killercup]

Good point! Let's add a test for these cases! I think we are only testing with shell internal commands (printenv) currently. That's obviously not good enough. (Okay if these tests are skipped with a comment as they are failing for now.) To solve this: Can we just run `which cargo` in the constructor and run the command with the full path to cargo? Ed Page <notifications@github.com> schrieb am Fr. 13. Okt. 2017 um 02:53:

…

I think this is a reasonable limitation, I just wanted to ensure it is noted somewhere. So ways I see forward for this - Rejecting it with label wontfix - Noting the limitation somewhere (an example workaround?) and closing this out with that (maybe still with a label wontfix). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOXw8hRk0mv2sZA92K1Ju7NUhped47ks5srrR9gaJpZM4P30-W> .

[Freyskeyd]

Yep if we wipe out the env we don't have access to the PATH.

Do we have a simple workaround? Saving the CARGO_* variables?

[epage]

To solve this: Can we just run which cargo in the constructor and run the command with the full path to cargo?

We'd have to keep in mind support for both Windows and Linux

Do we have a simple workaround? Saving the CARGO_* variables?

I was thinking of contributing to Environment a inherit_var(key) so clients could work around this more easily.

The main question is what the API should look like. As Environment grows different var manipulation functions (inherit, append, etc), should they be var_append, inherit_var, etc or var(key).inherit(), var(key).append(text), etc?

[sevagh]

Just to confirm that I expected the with_env(&vec[("MY_ENV_VAR", "MY_VAL")] to Just Work(TM) and it didn't - I had to use Environment::inherit().insert("MY_ENV_VAR", "MY_VAL").

Previously, I used to use https://doc.rust-lang.org/1.1.0/std/process/struct.Command.html#method.env - where:

let mut cmd = std::process::Command();
cmd.env("MY_ENV_VAR", "MY_VAL");

The usage there is just to append to the inherited environment variables, not to totally clear them.

I find the fact that with_env erases all the inherited env vars to be jarring. Any opinions?

[epage]

To not detract from the discussion in this thread, I opened #58

[luser]

I don't know if this is new, but the cargo docs say that cargo sets the CARGO env var to the path to the cargo binary in use, so you ought to just be able to use env!("CARGO").

[epage]

Thanks for looking into this!

CARGO - Path to the cargo binary performing the build.

Sounds like it is literally the cargo binary and not the binary cargo is producing but some of the other variables might be helpful.

EDIT: Oh. right, that'd still allow us to delegate to cargo for running the binary

[luser]

FWIW, I used $CARGO (along with assert-cli) in a test I wrote today:
https://github.com/mozilla/sccache/blob/2d9bdc1e8fb1fa5a531da2930670bbfcb66f78a0/tests/sccache_cargo.rs#L48

[killercup]

Good idea using env!("CARGO")!

I think the CI problems blocking #54 (which should also fix this) are resolves and we can land this (and #52) after a rebase.