-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allow repository rules to report env vars they're sensitive to later in the process #19511
Comments
@meteorcloudy Looking at the "help wanted" label, how could a volunteer get started on this one? Are any Googlers available to steer folks? As a naive outsider, illicitonion's 2nd suggestion seems straightforward to implement, since the semantics could be similar to RepositoryFunction's handling of # foo.bzl
def _derive_env(s):
return s.upper() + "_ROOT"
def _impl(rctx):
# equivalent to rctx.os.environ.get("MYNAME_ROOT"), but adds
# ENV:MYNAME_ROOT key to RepositoryFunction marker
value = rctx.env(_derive_env(rctx.name))
myreporule = repository_rule(_impl, attrs = {...})
# WORKSPACE
myreporule(name = "myname")
|
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 bazelbuild#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.
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 bazelbuild#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.
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. Closes #20787. PiperOrigin-RevId: 599568358 Change-Id: I2c1948cd23643d28bf1d41e9baaf98a902112cc7
…riable deps (#20944) 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. RELNOTES: Added a new method `repository_ctx.getenv`, which allows Starlark repository rules to declare environment variable dependencies during the fetch, instead of upfront using `repository_rule.environ`. Closes #20787. Commit c230e39 PiperOrigin-RevId: 599568358 Change-Id: I2c1948cd23643d28bf1d41e9baaf98a902112cc7 Co-authored-by: Ryan Beasley <beasleyr@vmware.com>
fixed by #20787. |
A fix for this issue has been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks! |
Description of the feature request:
Right now, if a repository rule is sensitive to an env var, it needs to declare it up-front on the
repository_rule
definition.This means that a repository rule can't safely accept the name of an env var as an attribute, and read that env var as part of its execution, as it can't know in advance what to tell Bazel when it needs to be invalidated.
Ideally there would be some way for a repository rule to tell Bazel that it's sensitive to a particular env var at runtime. Some options I can imagine:
repository_ctx
.repository_ctx.os.environ
to look for accesses.Which category does this issue belong to?
External Dependency
What underlying problem are you trying to solve with this feature?
I have a repository rule which is responsible for looking at the environment to work out information that will be used when stamping artifacts with version numbers. Currently I need to generate this
repository_rule
call in a function in order to capture the env var name and set theenviron
argument, but discussion #19459 suggests this is undesirable.Which operating system are you running Bazel on?
No response
What is the output of
bazel info release
?No response
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: