-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bazel query doesn't return the .bzl files that load external repositories #14280
Comments
@linzhp If possible you can try on other OS, such as on Linux. |
Tried on Linux, and got the same result. Updated the description. |
The io_bazel_rules_go only used in the workplace, so this is not a problem。 |
@gregestren I think this is a bug, not a feature request. |
@linzhp noted. I marked it as such because I'm not sure if this is query processing something incorrectly vs. just not being updated for external repo support for cases like this. I'm happy to let you and the domain experts (labeled on the issue) clarify as makes sense between you. |
This is an alternative approach to fix bazelbuild#14280. It adds transitive closure of Starlark dependencies to `//external` package when loading `WORKSPACE` file, so it can be processed in the same way as `BUILD` files during query execution. Comparing to the approach taken in bazelbuild#14497, this approach is less intrusive, but not able to distinguish the extension files needed by `//external:foo` and `//external:bar`, meaning `buildfiles(//external:foo)` returns the same result as `buildfiles(//external:*)`. However, this behavior is consistent with other packages. For example, `buildfiles(//foo:bar)` has the same result as `buildfiles(//foo:*)`. Closes bazelbuild#14630. PiperOrigin-RevId: 424092916 (cherry picked from commit a6c3f23)
This is an alternative approach to fix bazelbuild#14280. It adds transitive closure of Starlark dependencies to `//external` package when loading `WORKSPACE` file, so it can be processed in the same way as `BUILD` files during query execution. Comparing to the approach taken in bazelbuild#14497, this approach is less intrusive, but not able to distinguish the extension files needed by `//external:foo` and `//external:bar`, meaning `buildfiles(//external:foo)` returns the same result as `buildfiles(//external:*)`. However, this behavior is consistent with other packages. For example, `buildfiles(//foo:bar)` has the same result as `buildfiles(//foo:*)`. Closes bazelbuild#14630. PiperOrigin-RevId: 424092916 (cherry picked from commit a6c3f23)
* Adding Starlark dependencies to the package //external This is an alternative approach to fix #14280. It adds transitive closure of Starlark dependencies to `//external` package when loading `WORKSPACE` file, so it can be processed in the same way as `BUILD` files during query execution. Comparing to the approach taken in #14497, this approach is less intrusive, but not able to distinguish the extension files needed by `//external:foo` and `//external:bar`, meaning `buildfiles(//external:foo)` returns the same result as `buildfiles(//external:*)`. However, this behavior is consistent with other packages. For example, `buildfiles(//foo:bar)` has the same result as `buildfiles(//foo:*)`. Closes #14630. PiperOrigin-RevId: 424092916 (cherry picked from commit a6c3f23) * Avoid bazel_module_test timeout on macos https://buildkite.com/bazel/bazel-bazel/builds/17785#9a1fb564-c6f9-4e69-ac8f-87c422a002b0 By setting the test size to "large". RELNOTES:None PiperOrigin-RevId: 409114345 (cherry picked from commit 1d99391) Co-authored-by: Zhongpeng Lin <[email protected]> Co-authored-by: pcloudy <[email protected]>
Description of the problem / feature request:
bazel query
doesn't return the.bzl
files that load an external repositoryBugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
bazel query 'buildfiles(//external:io_bazel_rules_go)'
in it.The query only returns
//external:WORKSPACE
, while@io_bazel_rules_go
is actually defined inhttp_archives.bzl
.What operating system are you running Bazel on?
macOS 12.0.1 and Linux 5.4.129
What's the output of
bazel info release
?release 4.2.1
Any other information, logs, or outputs that you want to share?
bazel query 'loadfiles(//external:io_bazel_rules_go)'
returns "Empty results".bazel query --output=xml '//external:io_bazel_rules_go'
returnsThe
generator_location
is empty.The text was updated successfully, but these errors were encountered: