bazelbuild / bazelbuild/bazel

Support matching on undeclared (optional) providers in aspects

Open
#29,621 1 comment 0 reactions 0 assignees View on GitHub
P4 team-Rules-API type: feature request undecided
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 16h
Merged PRs (30d)
72

Description

### Description of the feature request:

Aspects are able to filter themselves to just rules that advertise a specified provider, avoiding the need to be configured if they go unused (faster builds).

However this relies on `rule(provides = [...]`), meaning providers must be pre-declared and that it will not work for providers which are not always returned.

It would be nice if `aspect(required_providers = [...])` considered what rules actually returned to better support many existing rules (`provides = [...]` is easily forgotten) and in the case of optional providers, allow aspect configuration to be deferred until it is proven to be necessary.

### Which category does this issue belong to?

Rules API

### What underlying problem are you trying to solve with this feature?

Optimising builds by avoiding unnecessary aspect application, which can lead to unnecessary analysis overhead (more targets, more repo fetches, etc).

### Which operating system are you running Bazel on?

Linux (Ubuntu)

### What is the output of `bazel info release`?

8.7.0

### 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 HEAD` ?

```text
NA
```

### Have you found anything relevant by searching the web?

The experimental `propagation_predicate` attribute ([proposal](https://docs.google.com/document/d/1LfglQ4naytDXmvT2Y8ptnoWOv8awhuaToNGmD2dRGdU)) has some overlap (even limited to loading phase information). Often the desired outcome can be approximated using the rule name alone (which I understand is given to the function), although it is much less extensible (and rather brittle).

### Any other information, logs, or outputs that you want to share?

_No response_

Contributor guide

Open the contributing guide

Research direction

Start by tracing the Rules API behavior for aspect(required_providers = [...]) and rule(provides = [...]), then compare it with the linked propagation_predicate proposal. Done means aspects can match providers actually returned by rules, including undeclared or optional providers, while deferring configuration until an optional provider is needed.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.