Add ability to unset variables with `--{action,host_action,repo,run,test}_env` by fmeum · Pull Request #26300 · bazelbuild/bazel

fmeum · 2025-06-14T20:27:46Z

The special syntax --action_env==NAME (or --action_env =NAME) can be used to unset the variable NAME (also for all the other --*_env flags). For the hermetic environments (--action_env, --host_action_env and --test_env), this clears any previous occurrences of --action_env=NAME=VALUE and --action_env=NAME. For the non-hermetic environments (--repo_env, --run_env), it additionally ensures that the given variable is explicitly unset in the final environment.

The particular syntax is somewhat quirky, but it is backwards compatible and doesn't limit the possible space of env variable names and values (as, say, --action_env=-NAME would).

This has a number of applications:

It makes it possible to unset variables that Bazel adds to the action environment by default, such as LD_LIBRARY_PATH and/or PATH. This is the primary motivation for this change as the author plans to add LC_CTYPE=C.UTF-8 in the future, which would result in Bazel actions supporting Unicode by default. Without the ability to remove this variable, users would be bound to have an LC_CTYPE variable set in all actions using use_default_shell_env (unless they use a Bazel wrapper that forces the variable to be unset and also specify --action_env=LC_CTYPE).
For the non-hermetic environments, it allows users to ensure that particularly problematic env vars don't make it into the environment. A hardcoded list of such variables was added to the run environment in bc83389, but with the new syntax, users have full flexibility and can apply the same type of "cleaning" to repo rule environments. This provides an onramp for a future in which --repo_env and/or --run_env could become hermetic.
It improves consistency by allowing clean --configs inheritance as well as appending to command-line invocations - previously, there was no way to fully undo the effect of an --action_env=FOO=bar.

Point 3 also explains why this change doesn't introduce dedicated --unset_*_env flags: they would introduce unpleasant confusion around precedence (what does --action_env=FOO=bar --unset_action_env=FOO --action_env=FOO=bar mean?) and/or introduce new flags that accumulate repeated uses with no way of resetting any particular ones.

RELNOTES[NEW]: The new --*_env==NAME syntax can be used with any of --action_env, --host_action_env, --repo_env, --run_env, and --test_env to undo any previous occurrences of the respective flags for that environment variable name. For --repo_env and --run_env, this also results in the variable being unset if it is set in the environment of the Bazel client.

meisterT · 2025-06-17T12:50:07Z

Not sure whether I should love or hate the =NAME hack. Did you also consider having explicit --unset_ prefixes, e.g. --unset_action_env=NAME?

fmeum · 2025-06-17T13:15:44Z

Not sure whether I should love or hate the =NAME hack. Did you also consider having explicit --unset_ prefixes, e.g. --unset_action_env=NAME?

I knew I forgot something when I wrote the PR description, added a new paragraph to explain why I didn't go with this approach. Just to be clear, I also don't like the new syntax, but it does at least have clear semantics.

fmeum · 2025-06-30T14:37:06Z

@meisterT Friendly ping

src/main/java/com/google/devtools/build/lib/analysis/config/FragmentOptions.java

src/main/java/com/google/devtools/build/lib/bazel/rules/BazelRuleClassProvider.java

src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java

meisterT

LGTM, but I would like to see a review from @tjgq as well

src/main/java/com/google/devtools/common/options/Converters.java

src/test/shell/integration/action_env_test.sh

src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java

src/main/java/com/google/devtools/build/lib/analysis/test/TestConfiguration.java

This PR introduces a new flag `--experimental_strict_repo_env` which stops repository rules and module extensions from inheriting the client environment (making `--repo_env=NAME` more than just an advisory notice). When enabled up to 2 environment variables will still be forwarded (unless overridden or explicitly removed via `--repo_env==VARNAME`, see #26300 for more details); - `PATH` - All platforms - `PATHEXT` - Windows See `test_execute_environment_strict_vars` in `src/test/shell/bazel/starlark_repository_test.sh` for a demonstration. Note that the behavior is different to the similarly named `--incompatible_strict_action_env`, which stops _all_ environment variables (`--action_env` affects actions with `use_default_shell_env = True`) except those specified within the defining rule. This is by design as repository rules operate in an inherently non-hermetic domain, covering roles such as integrating with the C/C++ toolchain installed on the host. It does not make sense to lock down environment variables _by default_, this is best left up to individual projects and users. This flag is marked experimental to allow for testing and requirement discovery (e.g. env vars other than `PATH` that should be included). Closes #10996 Closes #24404. PiperOrigin-RevId: 836494750 Change-Id: Ic05e5ca47a14badb2cd23f810e775c3341ddfaa8

This PR introduces a new flag `--experimental_strict_repo_env` which stops repository rules and module extensions from inheriting the client environment (making `--repo_env=NAME` more than just an advisory notice). When enabled up to 2 environment variables will still be forwarded (unless overridden or explicitly removed via `--repo_env==VARNAME`, see bazelbuild#26300 for more details); - `PATH` - All platforms - `PATHEXT` - Windows See `test_execute_environment_strict_vars` in `src/test/shell/bazel/starlark_repository_test.sh` for a demonstration. Note that the behavior is different to the similarly named `--incompatible_strict_action_env`, which stops _all_ environment variables (`--action_env` affects actions with `use_default_shell_env = True`) except those specified within the defining rule. This is by design as repository rules operate in an inherently non-hermetic domain, covering roles such as integrating with the C/C++ toolchain installed on the host. It does not make sense to lock down environment variables _by default_, this is best left up to individual projects and users. This flag is marked experimental to allow for testing and requirement discovery (e.g. env vars other than `PATH` that should be included). Closes bazelbuild#10996 Closes bazelbuild#24404. PiperOrigin-RevId: 836494750 Change-Id: Ic05e5ca47a14badb2cd23f810e775c3341ddfaa8

This PR introduces a new flag `--experimental_strict_repo_env` which stops repository rules and module extensions from inheriting the client environment (making `--repo_env=NAME` more than just an advisory notice). When enabled up to 2 environment variables will still be forwarded (unless overridden or explicitly removed via `--repo_env==VARNAME`, see #26300 for more details); - `PATH` - All platforms - `PATHEXT` - Windows See `test_execute_environment_strict_vars` in `src/test/shell/bazel/starlark_repository_test.sh` for a demonstration. Note that the behavior is different to the similarly named `--incompatible_strict_action_env`, which stops _all_ environment variables (`--action_env` affects actions with `use_default_shell_env = True`) except those specified within the defining rule. This is by design as repository rules operate in an inherently non-hermetic domain, covering roles such as integrating with the C/C++ toolchain installed on the host. It does not make sense to lock down environment variables _by default_, this is best left up to individual projects and users. This flag is marked experimental to allow for testing and requirement discovery (e.g. env vars other than `PATH` that should be included). Closes #10996 Closes #24404. PiperOrigin-RevId: 836494750 Change-Id: Ic05e5ca47a14badb2cd23f810e775c3341ddfaa8 Commit 60bc017 Co-authored-by: Jordan Mele <jordan.mele@outlook.com.au>

This PR introduces a new flag `--experimental_strict_repo_env` which stops repository rules and module extensions from inheriting the client environment (making `--repo_env=NAME` more than just an advisory notice). When enabled up to 2 environment variables will still be forwarded (unless overridden or explicitly removed via `--repo_env==VARNAME`, see bazelbuild#26300 for more details); - `PATH` - All platforms - `PATHEXT` - Windows See `test_execute_environment_strict_vars` in `src/test/shell/bazel/starlark_repository_test.sh` for a demonstration. Note that the behavior is different to the similarly named `--incompatible_strict_action_env`, which stops _all_ environment variables (`--action_env` affects actions with `use_default_shell_env = True`) except those specified within the defining rule. This is by design as repository rules operate in an inherently non-hermetic domain, covering roles such as integrating with the C/C++ toolchain installed on the host. It does not make sense to lock down environment variables _by default_, this is best left up to individual projects and users. This flag is marked experimental to allow for testing and requirement discovery (e.g. env vars other than `PATH` that should be included). Closes bazelbuild#10996 Closes bazelbuild#24404. PiperOrigin-RevId: 836494750 Change-Id: Ic05e5ca47a14badb2cd23f810e775c3341ddfaa8

fmeum changed the title ~~Support unsetting variables via --*_env~~ Allow variables to be unset in --{action,repo,run,test}_env Jun 15, 2025

fmeum changed the title ~~Allow variables to be unset in --{action,repo,run,test}_env~~ Allow variables to be unset in --{action,host_action,repo,run,test}_env Jun 15, 2025

fmeum force-pushed the unset-env branch 2 times, most recently from 4b0b475 to 8917c42 Compare June 16, 2025 13:53

brentleyjones changed the title ~~Allow variables to be unset in --{action,host_action,repo,run,test}_env~~ Add ability to unset variables with --{action,host_action,repo,run,test}_env Jun 16, 2025

fmeum marked this pull request as ready for review June 16, 2025 14:38

fmeum requested a review from a team as a code owner June 16, 2025 14:39

fmeum requested review from aranguyen and removed request for a team June 16, 2025 14:39

github-actions bot added team-Configurability platforms, toolchains, cquery, select(), config transitions awaiting-review PR is awaiting review from an assigned reviewer labels Jun 16, 2025

fmeum requested review from meisterT and tjgq and removed request for aranguyen June 16, 2025 14:39

fmeum added team-Core Skyframe, bazel query, BEP, options parsing, bazelrc and removed team-Configurability platforms, toolchains, cquery, select(), config transitions labels Jun 16, 2025

meisterT reviewed Jul 4, 2025

View reviewed changes

fmeum force-pushed the unset-env branch from 8917c42 to 553a980 Compare July 5, 2025 13:01

fmeum requested a review from meisterT July 5, 2025 13:01

meisterT approved these changes Jul 7, 2025

View reviewed changes

tjgq requested changes Jul 7, 2025

View reviewed changes

fmeum requested a review from tjgq July 7, 2025 16:21

tjgq approved these changes Jul 8, 2025

View reviewed changes

tjgq added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Jul 8, 2025

fmeum added 2 commits July 15, 2025 10:03

Support unsetting variables via --*_env

498ef40

Address comments

3fe6231

fmeum added 3 commits July 15, 2025 10:03

Refactor to a sealed interface

2c9e7f1

Add code tags

c23cd59

Add tests

5acba15

meteorcloudy force-pushed the unset-env branch from cac9d1b to 5acba15 Compare July 15, 2025 08:03

copybara-service bot closed this in 863d5ce Jul 18, 2025

github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Jul 18, 2025

Silic0nS0ldier mentioned this pull request Jul 19, 2025

Add --experimental_strict_repo_env option #24404

Closed

bazel-io mentioned this pull request Nov 25, 2025

[9.0.0] Add --experimental_strict_repo_env option #27780

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ability to unset variables with `--{action,host_action,repo,run,test}_env`#26300

Add ability to unset variables with `--{action,host_action,repo,run,test}_env`#26300
fmeum wants to merge 5 commits intobazelbuild:masterfrom
fmeum:unset-env

fmeum commented Jun 14, 2025 •

edited

Loading

Uh oh!

meisterT commented Jun 17, 2025

Uh oh!

fmeum commented Jun 17, 2025

Uh oh!

fmeum commented Jun 30, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

meisterT left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

fmeum commented Jun 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

meisterT commented Jun 17, 2025

Uh oh!

fmeum commented Jun 17, 2025

Uh oh!

fmeum commented Jun 30, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

meisterT left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fmeum commented Jun 14, 2025 •

edited

Loading