Question
error: no such package '//third_party/protobuf' during Bazel analysis
Sora Lane
0 reputation · 26 Sept 2024, 04:33 UTC
12.3K views1
Loading…
0 reputation · 26 Sept 2024, 04:33 UTC
Understand why Bazel emits the error “error: no such package” for a target that appears to have a correct BUILD file, focusing on the analysis phase and how the message varies across Bazel versions.
In Bazel 5.x the error includes the missing package path, whereas Bazel 4.x may omit the path unless the build is run with --verbose_fail_output. The experimental flag --experimental_repo_remote can change repository layout visibility and may mask the error under certain configurations. The resolver responsible is the Package.java component that scans the directory structure for BUILD files.
--experimental_repo_remote flag influence package visibility and error reporting?34775 reputation · 26 Sept 2024, 10:34 UTC
Bazel analysis fails with "error: no such package '//third_party/protobuf'" when the analysis phase cannot locate a package at the workspace-relative path third_party/protobuf. For an external dependency like protobuf this almost always means the repository that should materialize that path is not declared, not fetched, or is named differently than the label used in your BUILD files.
bazel--verbose_fail_output. This change can break automated error-parsing scripts that expect a stable format across versions.--experimental_repo_remote changes how repository rules are evaluated and materialized. With remote repository execution the local workspace layout can appear incomplete during analysis, which can mask or delay the "no such package" error until later phases.The question notes the resolver is Package.java scanning the directory structure for BUILD files. In practice the analysis failure for //third_party/protobuf is most commonly an external repository problem, not a missing BUILD file in the source tree. Bazel does not look for a workspace directory named third_party/protobuf unless a repository rule creates it. Manually creating that directory is ignored or overwritten because external repositories live under Bazel's output base.
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "protobuf",
...
)name matches the label referenced in your BUILD files. If your code references //third_party/protobuf, the repository name and mapping must resolve to that path.bazel query //third_party/protobuf:allbazel sync
bazel build //...One diagnostic detail that changes the recommendation: the exact repository rule name and how it is mapped to //third_party/protobuf in your WORKSPACE. If you can share the relevant http_archive or new_git_repository stanza and the label used in the failing target, the fix can be confirmed without guessing the version or mapping.
Note on versions: ensure the protobuf version declared in the repository rule matches what your BUILD files expect. Mismatched versions can allow analysis to succeed but cause compilation errors later.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 26 Sept 2024, 15:57 UTC
To clarify the behavior of the Package.java resolver: it is important to distinguish whether //third_party/protobuf is intended as a local package or an external repository alias. In Bazel, a label starting with // refers to the main workspace. If the project follows a vendoring pattern where dependencies are checked into the source tree, the resolver expects a physical third_party/protobuf/BUILD file relative to the workspace root.
If the dependency is meant to be external, the label should typically be @protobuf//.... A common cause for this specific error is a mismatch in the WORKSPACE or MODULE.bazel file where a local third_party directory is used as a proxy for external code, but the required symlinks or files are missing from the local checkout. To verify visibility, run:
bazel query //third_party/protobuf:...If this returns the same "no such package" error, the resolver has confirmed the absence of a BUILD file at that exact filesystem path, regardless of any external repository definitions.