Configurable //experimental-like semantics
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 75
Description
### Description of the feature request:
Blaze treats the `//experimental` hierarchy specially. Bazel once did as well, but it eventually surprised someone because it wasn't documented and then got removed. AFAIK, the special handling boils down to four major things:
1. Exclusion from target pattern expansion like `//...`
2. Graph edges may be outgoing, but not incoming
3. Ignoring visibility checks
4. Ignoring testonly checks
We would like to invoke this behavior externally, but to eliminate the surprise factor, do so in a configurable way like .bazelrc options or possibly even REPO.bazel directives. Conceptually, we can do all these independently, though one could also argue that the simplicity of controlling them all with one knob is preferable. Discussion is welcome so we can implement this the right way.
### Which category does this issue belong to?
Loading API
### What underlying problem are you trying to solve with this feature?
Isolation of experimental code from prod code and atomic changes of both
### Which operating system are you running Bazel on?
Ubuntu 20.04
### What is the output of `bazel info release`?
release 7.5.0-1
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
Built from source with a patch which implements part of this feature
### What's the output of `git remote get-url origin; git rev-parse HEAD` ?
```text
```
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start with Bazel's Loading API and investigate the existing //experimental handling described in the issue. Compare the four proposed semantics and determine whether they should be independently configurable or controlled by one bazelrc option or REPO.bazel directive. Done means the configuration model and its behavior across target expansion, graph edges, visibility, and testonly checks are specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100