bazelbuild / bazelbuild/bazel

glob(allow_empty=False) evaluated unconditionally; cannot be guarded by select

Open
#25,361 3 comments 0 reactions 0 assignees View on GitHub
P3 team-Configurability team-Core team-Documentation team-Loading-API type: bug
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 18h
Merged PRs (30d)
75

Description

### Description of the bug:

BUILD files' `glob` expressions seem to be evaluated unconditionally, preventing users from `select`ing between different `glob` patterns based on a build condition. In light of the `--incompatible_disallow_empty_glob` flag flip, builds may now error when ostensibly inapplicable `glob`s don't match anything.

In our case, we have instances where we choose between glob patterns based on the host operating system. (Our case involves repository rules, where the outputs fetched by the repo rule impl may vary by platform.) As a result of the flag flip, I'll need to scrub all instances of `glob` and inject an `allow_empty=True` as needed, which can be misleading to users/readers. (That said, I totally agree w/ the flag flip. We really would like `allow_empty=False` to be the default.)

If this is working as intended, then I'd like to suggest this become a documentation bug. (If that's the case, then my gut feeling is that this limitation should be noted at https://bazel.build/rules/lib/globals/build#glob .)

### Which category does this issue belong to?

Core, Configurability, Loading API, Documentation

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Example from Linux or macOS:

```console
$ touch MODULE.bazel
$ cat >BUILD.bazel <<"EOF"
genrule(
name = "demo",
outs = ["demo.out"],
srcs = select({
"@platforms//os:windows": glob(["*.windows"]),
"//conditions:default": glob(["*.bazel"]),
}),
cmd = "echo $(SRCS); touch $@",
)
EOF
$ bazelisk build :demo
...
ERROR: Traceback (most recent call last):
File "/.../BUILD.bazel", line 5, column 35, in
"@platforms//os:windows": glob(["*.windows"]),
Error in glob: glob pattern '*.windows' didn't match anything, but allow_empty is set to False (the default value of allow_empty can be set with --incompatible_disallow_empty_glob).
$ USE_BAZEL_VERSION=last_green bazelisk --output_user_root=$XDG_CACHE_HOME/bazel build :demo
2025/02/21 17:13:57 Using unreleased version at commit 80a9971055c90670effbf4f1fec53347bd0f0e86
2025/02/21 17:13:57 Downloading https://storage.googleapis.com/bazel-builds/artifacts/centos7/80a9971055c90670effbf4f1fec53347bd0f0e86/bazel...
Extracting Bazel installation...
Starting local Bazel server (no_version) and connecting to it...
INFO: Invocation ID: a33f1811-b015-49bd-8e70-6ce480274903
ERROR: Traceback (most recent call last):
File "/.../BUILD.bazel", line 5, column 35, in
"@platforms//os:windows": glob(["*.windows"]),
Error in glob: glob pattern '*.windows' didn't match anything, but allow_empty is set to False (the default value of allow_empty can be set with --incompatible_disallow_empty_glob).
```

Commenting out the `@platforms//os:windows` condition, which should be a no-op when invoked on Linux/macOS, yields a successful build.

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

Linux

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

release 8.1.0 or development version (see above)

### 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

```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

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

- https://github.com/bazelbuild/bazel/issues/20377#issuecomment-2400608165

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

_No response_

Contributor guide

Open the contributing guide

Research direction

Reproduce the behavior using the BUILD.bazel example with Bazel 8.1.0 and the bazelisk command shown. Read the glob and select documentation at bazel.build/rules/lib/globals/build#glob, then determine whether unconditional evaluation is intended; completion would require either documented behavior or an agreed implementation change with regression coverage.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.