| --- | 
 | layout: documentation | 
 | title: Bazel query how-to | 
 | --- | 
 | <h1>Bazel Query How-To</h1> | 
 |  | 
 | <p> | 
 |   This page covers how to get started using Bazel's query language to trace | 
 |   dependencies in your code. | 
 | </p> | 
 |  | 
 | <p> | 
 |   For a language details and <code>--output</code> flag details, please see the | 
 |   reference manuals, <a href="query.html">Bazel query reference</a> | 
 |   and <a href="cquery.html">Bazel cquery reference</a>. You can get help by | 
 |   typing <code>bazel help query</code> or <code>bazel help cquery</code> on the | 
 |   command line. | 
 | </p> | 
 |  | 
 | <p> | 
 |   To execute a query while ignoring errors such as missing targets, use the | 
 |   <code>--keep_going</code> flag. | 
 | </p> | 
 |  | 
 |  | 
 | <h2 id="Finding_the_Dependencies_of_a_Ru">Finding the dependencies of a rule</h2> | 
 |  | 
 | <p>To see the dependencies of <code>//foo</code>, use the | 
 | <code>deps</code> function in bazel query:</p> | 
 |  | 
 | <pre> | 
 | $ bazel query "deps(//foo)" | 
 | //foo:foo | 
 | //foo:foo-dep | 
 | ... | 
 | </pre> | 
 |  | 
 | <p>This is the set of all targets required to build <code>//foo</code>.</p> | 
 |  | 
 | <h2 id="Tracing_the_Dependency_Chain_bet">Tracing the dependency chain between two packages</h2> | 
 |  | 
 | <p>The library <code>//third_party/zlib:zlibonly</code> isn't in the BUILD file for | 
 | <code>//foo</code>, but it is an indirect dependency. How can | 
 | we trace this dependency path?  There are two useful functions here: | 
 | <code>allpaths</code> and <code>somepath</code>. You may also want to exclude | 
 | tooling dependencies with <code>--notool_deps</code> if you care only about | 
 | what is included in the artifact you built, and not every possible job. | 
 |  | 
 | <p>To visualize the graph of all dependencies, pipe the bazel query output through | 
 |   the <code>dot</code> command-line tool:</p> | 
 | <pre> | 
 | $ bazel query "allpaths(//foo, third_party/...)" --notool_deps --output graph | dot -Tsvg > /tmp/deps.svg | 
 | </pre> | 
 |  | 
 | <p> | 
 |   Note that <code>dot</code> supports other image formats, just replace <code>svg</code> with the | 
 |   format identifier, for example, <code>png</code>. | 
 | </p> | 
 |  | 
 | <p>When a dependency graph is big and complicated, it can be helpful start with a single path:</p> | 
 |  | 
 | <pre> | 
 | $ bazel query "somepath(//foo:foo, third_party/zlib:zlibonly)" | 
 | //foo:foo | 
 | //translations/tools:translator | 
 | //translations/base:base | 
 | //third_party/py/MySQL:MySQL | 
 | //third_party/py/MySQL:_MySQL.so | 
 | //third_party/mysql:mysql | 
 | //third_party/zlib:zlibonly | 
 | </pre> | 
 |  | 
 | <p>If you do not specify <code>--output graph</code> with <code>allpaths</code>, | 
 | you will get a flattened list of the dependency graph.</p> | 
 | <pre> | 
 | $ bazel query "allpaths(//foo, third_party/...)" | 
 |   ...many errors detected in BUILD files... | 
 | //foo:foo | 
 | //translations/tools:translator | 
 | //translations/tools:aggregator | 
 | //translations/base:base | 
 | //tools/pkg:pex | 
 | //tools/pkg:pex_phase_one | 
 | //tools/pkg:pex_lib | 
 | //third_party/python:python_lib | 
 | //translations/tools:messages | 
 | //third_party/py/xml:xml | 
 | //third_party/py/xml:utils/boolean.so | 
 | //third_party/py/xml:parsers/sgmlop.so | 
 | //third_party/py/xml:parsers/pyexpat.so | 
 | //third_party/py/MySQL:MySQL | 
 | //third_party/py/MySQL:_MySQL.so | 
 | //third_party/mysql:mysql | 
 | //third_party/openssl:openssl | 
 | //third_party/zlib:zlibonly | 
 | //third_party/zlib:zlibonly_v1_2_3 | 
 | //third_party/python:headers | 
 | //third_party/openssl:crypto | 
 | </pre> | 
 |  | 
 | <h3 id="Aside_implicit_dependencies">Aside: implicit dependencies</h3> | 
 |  | 
 | <p>The BUILD file for <code>//foo</code> never references | 
 | <code>//translations/tools:aggregator</code>. So, where's the direct dependency?</p> | 
 |  | 
 | <p>Certain rules include implicit dependencies on additional libraries or tools. | 
 | For example, to build a <code>genproto</code> rule, you need first to build the Protocol | 
 | Compiler, so every <code>genproto</code> rule carries an implicit dependency on the | 
 | protocol compiler. These dependencies are not mentioned in the build file, | 
 | but added in by the build tool. The full set of implicit dependencies is | 
 |   currently undocumented. Using <code>--noimplicit_deps</code> allows you to filter out | 
 |   these deps from your query results. For cquery, this will include resolved toolchains. | 
 |  | 
 | <h2 id="Reverse_Dependencies">Reverse dependencies</h2> | 
 |  | 
 | <p>You might want to know the set of targets that depends on some target. e.g., | 
 | if you're going to change some code, you might want to know what other code | 
 | you're about to break. You can use <code>rdeps(u, x)</code> to find the reverse | 
 | dependencies of the targets in <code>x</code> within the transitive closure of <code>u</code>.</p> | 
 |  | 
 | Bazel's <a href="query.html#sky-query">Sky Query</a> supports the <code>allrdeps</code> | 
 | function, which allows you to query <code>rdeps</code> in a universe you specify. | 
 | <h2 id="Miscellaneous_Uses">Miscellaneous uses</h2> | 
 |  | 
 | <p>You can use <code>bazel query</code> to analyze many dependency relationships.</p> | 
 |  | 
 | <h3 id="What_exists_">What exists ...</h3> | 
 |  | 
 | <h4 id="What_packages_exist_beneath_foo_">What packages exist beneath <code>foo</code>?</h4> | 
 |  | 
 | <pre>bazel query 'foo/...' --output package</pre> | 
 |  | 
 | <h4 id="What_rules_are_defined_in_the_foo">What rules are defined in the <code>foo</code> package?</h4> | 
 |  | 
 | <pre>bazel query 'kind(rule, foo:*)' --output label_kind</pre> | 
 |  | 
 | <h4 id="What_files_are_generated_by_rule">What files are generated by rules in the <code>foo</code> package?</h4> | 
 |  | 
 | <pre>bazel query 'kind("generated file", //foo:*)'</pre> | 
 |  | 
 | <h4 id="What_targets_are_generated_by_macro">What targets are generated by starlark macro <code>foo</code>?</h4> | 
 |  | 
 | <pre>bazel query 'attr(generator_function, foo, //path/to/search/...)'</pre> | 
 |  | 
 | <h4 id="What_s_the_set_of_BUILD_files_ne">What's the set of BUILD files needed to build <code>//foo</code>?</h4> | 
 |  | 
 | <pre>bazel query 'buildfiles(deps(//foo))' | cut -f1 -d:</pre> | 
 |  | 
 | <h4 id="What_are_the_individual_tests_th">What are the individual tests that a <code>test_suite</code> expands to?</h4> | 
 |  | 
 | <pre>bazel query 'tests(//foo:smoke_tests)'</pre> | 
 |  | 
 | <h4 id="Which_of_those_are_C_tests_">Which of those are C++ tests?</h4> | 
 |  | 
 | <pre>bazel query 'kind(cc_.*, tests(//foo:smoke_tests))'</pre> | 
 |  | 
 | <h4 id="Which_of_those_are_small_Medium_">Which of those are small?  Medium?  Large?</h4> | 
 |  | 
 | <pre> | 
 | bazel query 'attr(size, small, tests(//foo:smoke_tests))' | 
 |  | 
 | bazel query 'attr(size, medium, tests(//foo:smoke_tests))' | 
 |  | 
 | bazel query 'attr(size, large, tests(//foo:smoke_tests))' | 
 | </pre> | 
 |  | 
 | <h4 id="What_are_the_tests_beneath_foo_t">What are the tests beneath <code>foo</code> that match a pattern?</h4> | 
 |  | 
 | <pre>bazel query 'filter("pa?t", kind(".*_test rule", //foo/...))'</pre> | 
 |  | 
 | <p>The pattern is a regex and is applied to the full name of the rule. It's similar to doing</p> | 
 |  | 
 | <pre>bazel query 'kind(".*_test rule", //foo/...)' | grep -E 'pa?t'</pre> | 
 |  | 
 | <h4 id="What_package_contains_file_java_">What package contains file <code>path/to/file/bar.java</code>?</h4> | 
 |  | 
 | <pre> bazel query path/to/file/bar.java --output=package</pre> | 
 |  | 
 | <h4 id="What_is_the_build_label_for_java">What is the build label for <code>path/to/file/bar.java?</code></h4> | 
 |  | 
 | <pre>bazel query path/to/file/bar.java</pre> | 
 |  | 
 | <h4 id="What_build_rule_contains_file_ja">What rule target(s) contain file <code>path/to/file/bar.java</code> as a source?</h4> | 
 |  | 
 | <pre> | 
 | fullname=$(bazel query path/to/file/bar.java) | 
 | bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)" | 
 | </pre> | 
 |  | 
 | <h3 id="What_package_dependencies_exist_">What package dependencies exist ...</h3> | 
 |  | 
 | <h4 id="What_packages_does_foo_depend_on">What packages does <code>foo</code> depend on? (What do I need to check out to build <code>foo</code>)</h4> | 
 |  | 
 | <pre>bazel query 'buildfiles(deps(//foo:foo))' --output package</pre> | 
 |  | 
 | <p>Note, <code>buildfiles</code> is required in order to correctly obtain all files | 
 | referenced by <code>subinclude</code>; see the reference manual for details.</p> | 
 |  | 
 | <h4 id="What_packages_does_the_foo_">What packages does the <code>foo</code> tree depend on, excluding <code>foo/contrib</code>?</h4> | 
 |  | 
 | <pre>bazel query 'deps(foo/... except foo/contrib/...)' --output package</pre> | 
 |  | 
 | <h3 id="What_rule_dependencies_exist_">What rule dependencies exist ...</h3> | 
 |  | 
 | <h4 id="What_genproto_rules_does_bar_">What genproto rules does bar depend upon?</h4> | 
 |  | 
 | <pre>bazel query 'kind(genproto, deps(bar/...))'</pre> | 
 |  | 
 | <h4 id="Find_the_definition_of_some_JNI_">Find the definition of some JNI (C++) library that is transitively depended upon by a Java binary rule in the servlet tree.</h4> | 
 |  | 
 | <pre>bazel query 'some(kind(cc_.*library, deps(kind(java_binary, //java/com/example/frontend/...))))' --output location</pre> | 
 |  | 
 | <h5 id="_Now_find_the_definitions_of_all">...Now find the definitions of all the Java binaries that depend on them</h5> | 
 |  | 
 | <pre>bazel query 'let jbs = kind(java_binary, //java/com/example/frontend/...) in | 
 |   let cls = kind(cc_.*library, deps($jbs)) in | 
 |     $jbs intersect allpaths($jbs, $cls)' | 
 | </pre> | 
 |  | 
 | <h3 id="What_file_dependencies_exist_">What file dependencies exist ...</h3> | 
 |  | 
 | <h4 id="What_s_the_complete_set_of_Java_">What's the complete set of Java source files required to build foo?</h4> | 
 |  | 
 | <p>Source files:</p> | 
 |  | 
 | <pre>bazel query 'kind("source file", deps(//path/to/target/foo/...))' | grep java$</pre> | 
 |  | 
 | <p>Generated files:</p> | 
 |  | 
 | <pre>bazel query 'kind("generated file", deps(//path/to/target/foo/...))' | grep java$</pre> | 
 |  | 
 | <h4 id="What_is_the_complete_set_of_Java">What is the complete set of Java source files required to build QUX's tests?</h4> | 
 |  | 
 | <p>Source files:</p> | 
 |  | 
 | <pre>bazel query 'kind("source file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$</pre> | 
 |  | 
 | <p>Generated files:</p> | 
 |  | 
 | <pre>bazel query 'kind("generated file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$</pre> | 
 |  | 
 | <h3 id="What_differences_in_dependencies">What differences in dependencies between X and Y exist ...</h3> | 
 |  | 
 | <h4 id="What_targets_does_foo_depend_on_">What targets does <code>//foo</code> depend on that <code>//foo:foolib</code> does not?</h4> | 
 |  | 
 | <pre>bazel query 'deps(//foo) except deps(//foo:foolib)'</pre> | 
 |  | 
 | <h4 id="What_C_libraries_do_the_foo_test">What C++ libraries do the <code>foo</code> tests depend on that the <code>//foo</code> production binary does <em>not</em> depend on?</h4> | 
 |  | 
 | <pre>bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'</pre> | 
 |  | 
 | <h3 id="Why_does_this_dependency_exist_">Why does this dependency exist ...</h3> | 
 |  | 
 | <h4 id="Why_does_bar_depend_on_groups">Why does <code>bar</code> depend on <code>groups2</code>?</h4> | 
 |  | 
 | <pre>bazel query 'somepath(bar/...,groups2/...:*)'</pre> | 
 |  | 
 | <p>Once you have the results of this query, you will often find that a single | 
 | target stands out as being an unexpected or egregious and undesirable | 
 | dependency of <code>bar</code>. The query can then be further refined to:</p> | 
 |  | 
 | <h4 id="Show_me_a_path_from_docker_updater">Show me a path from <code>docker/updater:updater_systest</code> (a <code>py_test</code>) to some <code>cc_library</code> that it depends upon:</h4> | 
 |  | 
 | <pre>bazel query 'let cc = kind(cc_library, deps(docker/updater:updater_systest)) in | 
 |   somepath(docker/updater:updater_systest, $cc)'</pre> | 
 |  | 
 | <h4 id="Why_does_library_photos_frontend">Why does library <code>//photos/frontend:lib</code> depend on two variants of the same library <code>//third_party/jpeglib</code> and <code>//third_party/jpeg</code>?</h4> | 
 |  | 
 | <p>This query boils down to: "show me the subgraph of <code>//photos/frontend:lib</code> that | 
 | depends on both libraries". When shown in topological order, the last element | 
 | of the result is the most likely culprit.</p> | 
 |  | 
 | <pre>bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib) | 
 |                 intersect | 
 |                allpaths(//photos/frontend:lib, //third_party/jpeg)' | 
 | //photos/frontend:lib | 
 | //photos/frontend:lib_impl | 
 | //photos/frontend:lib_dispatcher | 
 | //photos/frontend:icons | 
 | //photos/frontend/modules/gadgets:gadget_icon | 
 | //photos/thumbnailer:thumbnail_lib | 
 | //third_party/jpeg/img:renderer | 
 | </pre> | 
 |  | 
 | <h3 id="What_depends_on_">What depends on  ...</h3> | 
 |  | 
 | <h4 id="What_rules_under_bar_depend_o">What rules under bar depend on Y?</h4> | 
 |  | 
 | <pre>bazel query 'bar/... intersect allpaths(bar/..., Y)'</pre> | 
 |  | 
 | <p>Note: <code>X intersect allpaths(X, Y)</code> is the general idiom for the query "which X | 
 | depend on Y?" If expression X is non-trivial, it may be convenient to bind a | 
 | name to it using <code>let</code> to avoid duplication.</p> | 
 |  | 
 | <h4 id="What_are_the_intra_package_direct_rdeps">What targets directly depend on T, in T's package?</h4> | 
 |  | 
 | <pre>bazel query 'same_pkg_direct_rdeps(T)'</pre> | 
 |  | 
 | <h3 id="How_do_I_break_a_dependency_">How do I break a dependency ...</h3> | 
 |  | 
 | <p><!-- TODO find a convincing value of X to plug in here --> | 
 |  | 
 | <h4 id="What_dependency_paths_do_I_have_">What dependency paths do I have to break to make <code>bar</code> no longer depend on X?</h4> | 
 |  | 
 | <p>To output the graph to a <code>svg</code> file:</p> | 
 |  | 
 | <pre>bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg</pre> | 
 |  | 
 | <h3 id="Misc_">Misc ...</h3> | 
 |  | 
 | <h4 id="How_many_sequential_steps_are_th">How many sequential steps are there in the <code>//foo-tests</code> build?</h4> | 
 |  | 
 | <p>Unfortunately, the query language can't currently give you the longest path | 
 | from x to y, but it can find the (or rather <em>a</em>) most distant node from the | 
 | starting point, or show you the <em>lengths</em> of the longest path from x to every | 
 | y that it depends on. Use <code>maxrank</code>:</p> | 
 |  | 
 | <pre>bazel query 'deps(//foo-tests)' --output maxrank | tail -1 | 
 | 85 //third_party/zlib:zutil.c</pre> | 
 |  | 
 | <p>The result indicates that there exist paths of length 85 that must occur in | 
 | order in this build.</p> |