bazelbuild / bazelbuild/bazel

Configurable //experimental-like semantics

Open
#25,279 1 comment 3 reactions 0 assignees View on GitHub
team-Loading-API type: feature request untriaged
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.