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

Allow repository rules to report env vars they're sensitive to later in the process #19511

Closed
illicitonion opened this issue Sep 13, 2023 · 3 comments
Labels
help wanted Someone outside the Bazel team could own this P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@illicitonion
Copy link
Contributor

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:

  1. Returning a provider-like object from the implementation function which has a field for env vars.
  2. A function that can be called on repository_ctx.
  3. If Bazel were being fancy, it could automatically detect env var reads by wrapping 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 the environ 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 returns development 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

@iancha1992 iancha1992 added the team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. label Sep 13, 2023
@meteorcloudy meteorcloudy added P2 We'll consider working on this in future. (Assignee optional) help wanted Someone outside the Bazel team could own this and removed untriaged labels Sep 14, 2023
@ghost
Copy link

ghost commented Nov 14, 2023

@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 rctx.path(label_type).

# 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")
  • Would need to make sure things play nice with --repo_env.

rbeasley added a commit to rbeasley/bazel that referenced this issue Jan 8, 2024
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.
rbeasley added a commit to rbeasley/bazel that referenced this issue Jan 11, 2024
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.
copybara-service bot pushed a commit that referenced this issue Jan 18, 2024
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
github-merge-queue bot pushed a commit that referenced this issue Jan 19, 2024
…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>
@Wyverald
Copy link
Member

fixed by #20787.

@iancha1992
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Someone outside the Bazel team could own this P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

6 participants