[rfc] Allow repository rules to lazily declare environment variable deps

[rbeasley]

This commit adds a new repository context method, getenv, which allows Starlark repository rule implementations to lazily declare environment variable dependencies. This is intended to allow repository rules to establish dependencies on environment variables whose names aren't known in advance.

This is work towards #19511.

Notes

• I don't speak Java, so expect funny smells and copypasta.
• rctx.getenv behaves similarly to Python's os.getenv.
• rctx.getenv is to environment variables what rctx.path(Label) is to files.

Future work

• Implement bzlmod support.

[rbeasley]

I reviewed the test failures, and they don't appear to be related to my changes. I don't think my change introduced thread/synchronization bugs, but I need to defer to the experts.

• https://buildkite.com/bazel/bazel-bazel-github-presubmit/builds/19155#018ce9a4-a2f0-43cf-a4ca-87a29e8c5093
  • src/test/java/com/google/devtools/build/lib/actions/ActionsTests succeeds locally.
  • starlark_repository_tests failed in all 3 attempts, but each attempt's failure reason was different. (Two instances had failed the test_starlark_headers_override_default_headers case, while the third failed the test_disable_download_should_prevent_downloading case.)

[Wyverald]

Thanks for the PR! I'll take a look in a minute. Anyhow the test failures are definitely unrelated; see #20790

[Wyverald]

thanks!

[brentleyjones]

@bazel-io flag

[Wyverald]

@bazel-io fork 7.1.0

[lberki]

What happens if one downgrades the Bazel version in an existing output base from one that supports the ENV: tag in marker files to one that doesn't?

[rbeasley]

What happens if one downgrades the Bazel version in an existing output base from one that supports the ENV: tag in marker files to one that doesn't?

@lberki Just to make sure I understand correctly, the ENV: tag already exists before this change and is populated according to repository_rule's environ attr. My change overloaded the ENV: tag to also support lazy env var deps via rctx.getenv.

With that, consider the following sequence of events:

• User upgrades to Bazel 7.1.0 (or some release containing this feature).
• User writes or updates a repository rule that uses rctx.env where ENV:key is added to the marker file lazily.

If the user downgrades Bazel to an older version, they'll have to revert their repository rule definition (because rctx.getenv doesn't exist in the older Bazel version). Since this involves changing the contents of the .bzl file where the rule is defined, the corresponding "rule key" would change (as pointed out by @Wyverald above at #20787 (comment)), voiding the marker entirely.

Does that sound right? Am I missing anything?

[lberki]

No, you are not missing anything -- I didn't realize in my (very literal) fever dream that resulted in the above comment that ENV: was already written to the marker files before this pull request. Sorry for the noise and carry on!