bazel query: query for effective values of attributes

[laszlocsomor]

Description of the problem / feature request:

Feature request: bazel query operating on the effective values of attributes, e.g. querying the visibility of a target if it uses the package-default visibility.

Example -- the query should return fg1 and fg2, but it only returns fg1:

C:\tmp\bzl>type a\BUILD
package(default_visibility = ["//visibility:public"])

filegroup(
    name = 'fg1',
    srcs = ['BUILD'],
    visibility=['//visibility:public'],
)

filegroup(
    name = 'fg2',
    srcs = ['BUILD'],
)

filegroup(
    name = 'fg3',
    srcs = ['BUILD'],
    visibility=['//visibility:private'],
)

C:\tmp\bzl>bazel --output_user_root=c:\tmp4 query --output=build //a:*
# C:/tmp/bzl/a/BUILD:14:1
filegroup(
  name = "fg3",
  visibility = ["//visibility:private"],
  srcs = ["//a:BUILD"],
)

# C:/tmp/bzl/a/BUILD:9:1
filegroup(
  name = "fg2",
  srcs = ["//a:BUILD"],
)

# C:/tmp/bzl/a/BUILD:3:1
filegroup(
  name = "fg1",
  visibility = ["//visibility:public"],
  srcs = ["//a:BUILD"],
)

C:\tmp\bzl>bazel --output_user_root=c:\tmp4 query attr(visibility, "//visibility:public", //a:*)
//a:fg1

Feature requests: what underlying problem are you trying to solve with this feature?

https://stackoverflow.com/questions/48025329

What operating system are you running Bazel on?

Windows 10

What's the output of bazel info release?

0.9.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

Not a git repo.

Have you found anything relevant by searching the web?

No open GitHub issues AFAICT.

[gregestren]

This is a weird one, because strictly speaking the value of fg2's visibility attribute is empty and default_visibility doesn't change that. Because that's a property of package, not fg2.

Bazel then resolves all this with

bazel/src/main/java/com/google/devtools/build/lib/packages/Rule.java

Line 636 in 076977e

* Returns the effective visibility of this Rule. Visibility is computed from

There's also the --default_visibility command-line flag.

But I get something intuitive gets lost in all this. If the workaround described in https://stackoverflow.com/questions/48025329 isn't sufficient, please re-ping here and we'll re-assess.

[pkbehera]

But I get something intuitive gets lost in all this. If the workaround described in https://stackoverflow.com/questions/48025329 isn't sufficient, please re-ping here and we'll re-assess.

Like you have said something intuitive is lost here. The workaround in SO works only partially.
If the visibility query can not give the result that is intuitive, then one should perhaps be able to query effective-visibility! No?

[gregestren]

I forgot about this, but what about the visible query function?

$ bazel query 'visible(//some_other_package:rule, //a:all)`
//a:fg2
//a:fg1

This returns the rules in //a that are visible to //some_other_package:rule.

It's not perfect because a rule could set visibility = "//some_other_package:__pkg__", which isn't the same as public visibility.

But I bet this could get you a lot closer to a satisfactory solution, at least for public visibility.

[gfl-chris]

visible is specific to visibility. What about other attributes like tags, for example? Is there a way to have bazel print the value of an(y) attribute of a set of targets?

[gregestren]

Chris,

For what purpose?

For example, why not just call $ cat foo/BUILD at the command line?

If you're looking for more structured operations, you can also play with query's --output flag:

$ bazel query '//foo:bar' --output=build
cc_library(
  name = "bar",
  srcs = ["//foo:bar.cc"],
)

$ bazel query '//foo:bar' --output=xml
<?xml version="1.1" encoding="UTF-8" standalone="no"?>
<query version="2">
    <rule class="cc_library" location="/usr/local/home/me/bazel/bazel-website/foo/BUILD:1:1" name="//foo:bar">
        <string name="name" value="bar"/>
        <list name="srcs">
            <label value="//foo:bar.cc"/>
        </list>
        <rule-input name="//foo:bar.cc"/>
        <rule-input name="@bazel_tools//tools/cpp:grep-includes"/>
        <rule-input name="@bazel_tools//tools/cpp:stl"/>
        <rule-input name="@bazel_tools//tools/cpp:toolchain"/>
        <rule-input name="@bazel_tools//tools/def_parser:def_parser"/>
    </rule>
</query>

$ bazel query '//foo:bar' --output=xml --noimplicit_deps
<?xml version="1.1" encoding="UTF-8" standalone="no"?>
<query version="2">
    <rule class="cc_library" location="/usr/local/home/me/bazel/bazel-website/foo/BUILD:1:1" name="//foo:bar">
        <string name="name" value="bar"/>
        <list name="srcs">
            <label value="//foo:bar.cc"/>
        </list>
        <rule-input name="//foo:bar.cc"/>
    </rule>
</query>

You can also use buildozer:

$ buildozer 'print srcs' //foo:bar
[bar.cc]

[uri-canva]

Can this be reopened? None of the suggested workarounds account for the default visibility of the package.

[gregestren]

What specifically are you trying to figure out (from your query)?

[uri-canva]

Same as the OP: the visibility of targets. bazel query //:foo --output xml will not show the visibility of the target if the package's default visibility is set, and will only show the label to a package group instead of all the targets in the package group. I have looked at https://stackoverflow.com/questions/48025329/how-to-find-all-publicly-visible-targets-in-a-bazel-workspace which you linked to before but I don't see any workarounds, only references to this issue. The visible verb in query returns the opposite of what both of us are trying to query: it returns which targets are visible to x, we want which targets x is visible to.

For context my use case is that I'm implementing a linter for our monorepo to enforce rules like "targets in //app/foo should be only visible to //app/foo", so that we can partition the monorepo into isolated subtrees that don't depend on each other. Basically like test_only, except for multiple different axes, not just test / non-test.

[uri-canva]

So right now we're prohibiting package groups and default visibilities so that the query can work in a simple way.

[gregestren]

This was the workaround - find targets that inherit default visibility.

Can you string a few calls together?

• query with --output=xml as described
• buildozer to find the package's default visibility
• either use the --output=xml result or the visibility ="" trick to find default visibility targets
• query a package group explicitly to find its contents (works with --output=xml)

And match accordingly.

I realize direct support would be more convenient. But it conceptually complicates the query language. We'd have to be extra cautious about vetting it as a proper feature request. That would require a deeper process than a quick fix. Given that I'd like to evaluate what's possible with workarounds as much as we can.

[uri-canva]

All those pieces put together achieve what we need, and I understand the concern about complicating the query language. Thanks for the help!