Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary cache invalidation when setting environment variables #12434

Closed
VivekPanyam opened this issue Aug 2, 2023 · 5 comments
Closed

Unnecessary cache invalidation when setting environment variables #12434

VivekPanyam opened this issue Aug 2, 2023 · 5 comments
Labels
A-environment-variables Area: environment variables A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@VivekPanyam
Copy link

VivekPanyam commented Aug 2, 2023

Problem

When an environment variable is set in configuration, build scripts unnecessarily rerun in the following scenarios:

  1. An env var defined in the configuration is explicitly set to the same value in the environment (e.g. FOO=BAR is set both in the env and in the config file)
$ cat .cargo/config.toml
[env]
FOO = "/some/path"

$ cargo build
$ export FOO="/some/path"
$ cargo build
$ # ^ Build scripts rerun
  1. An env var is defined with force = true, but explicitly setting that environment variable causes build scripts to rerun
$ cat .cargo/config.toml
[env]
SOMETHING = {value = "./a/path", relative = true, force = true}

$ cargo build
$ export SOMETHING=asdf # any value
$ cargo build
$ # ^ Build scripts rerun

Steps

No response

Possible Solution(s)

No response

Notes

These cases were found when running cargo build from a process running under cargo run. The nested build had env vars in the config explicitly set in its environment. Removing these vars caused build scripts to not rerun and caches to be reused.

Version

cargo 1.70.0 (ec8a8a0ca 2023-04-25)
release: 1.70.0
commit-hash: ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc
commit-date: 2023-04-25
host: x86_64-unknown-linux-gnu
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1t)
os: Ubuntu 20.04 (focal) [64-bit]
@VivekPanyam VivekPanyam added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Aug 2, 2023
@weihanglo
Copy link
Member

weihanglo commented Aug 17, 2023

Good catch. Thanks for reporting this!

We should perhaps switch from std::env::var to Config::get_env and Config::env_config.

// TODO: This is allowed at this moment. Should figure out if it makes
// sense if permitting to read env from the config system.
#[allow(clippy::disallowed_methods)]
fn from_env<K: AsRef<str>>(key: K) -> LocalFingerprint {
let key = key.as_ref();
let var = key.to_owned();
let val = env::var(key).ok();
LocalFingerprint::RerunIfEnvChanged { var, val }
}


@rustbot label +A-rebuild-detection +A-environment-variables -S-triage +S-accepted

@rustbot rustbot added A-environment-variables Area: environment variables A-rebuild-detection Area: rebuild detection and fingerprinting S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review and removed S-triage Status: This issue is waiting on initial triage. labels Aug 17, 2023
@heisen-li
Copy link
Contributor

@rustbot claim

@weihanglo
Copy link
Member

See also #10358.

@heisen-li
Copy link
Contributor

Sorry, did I make a mistake?

It seems to have nothing to do with environment variables. As long as cargo build is executed repeatedly, the build script will be run repeatedly.

@weihanglo
Copy link
Member

Going to close this, as it is essentially #10358. I'll post an update there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-environment-variables Area: environment variables A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

No branches or pull requests

4 participants