Skip to content
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

Adding Starlark dependencies to the package //external #14630

Closed
wants to merge 2 commits into from

Conversation

linzhp
Copy link
Contributor

@linzhp linzhp commented Jan 23, 2022

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:*).

Copy link
Contributor

@janakdr janakdr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is certainly much cleaner than the other approach, I don't see any real issues. Is there enough information in it for your purposes, though?

@linzhp
Copy link
Contributor Author

linzhp commented Jan 24, 2022

Is there enough information in it for your purposes, though?

Thanks for asking. Yes, the query result of this approach is a superset of the query result of the other approach. I am trying to use bazel query to figure out the set of files needed to run bazel build in a git sparse checkout. It's fine to stay on the safe side and check out a bit more files.

@bazel-io bazel-io closed this in a6c3f23 Jan 25, 2022
@linzhp linzhp deleted the buildfiles2 branch January 25, 2022 17:16
brentleyjones pushed a commit to brentleyjones/bazel that referenced this pull request Mar 7, 2022
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)
brentleyjones pushed a commit to brentleyjones/bazel that referenced this pull request Mar 7, 2022
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)
Wyverald pushed a commit that referenced this pull request Mar 8, 2022
* 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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bazel query doesn't return the .bzl files that load external repositories
2 participants