Starting with #6501 (comment), it seems like it would be both useful and fun to merge our target selection options (currently: --changed-parent, --owner-of, and the filter, paths?, and dependees goals) into a composable interface. One existing example (ish) of this is the bazel query language, although that tries to output graphs, and has its own command-line goal.
Rather than making it into its own goal, it seems like making an option --query which wraps our existing target selection logic, and then allowing goals such as list, compile, or test to use the selected targets the same way they currently use e.g. --changed-parent seems like a great way to incorporate our current mechanisms, while making the use of multiple selection mechanisms significantly more performant by allowing query composition instead of invoking multiple pants processes, as well as by use of the v2 engine.
Another specific and possibly important point from #6501 (comment) is that while composing expressions in the bazel query language is done by nesting function calls, we can consider what should be a strict extension to that language by incorporating the | operator à la jq. Other extensions to that language would involve incorporating our existing selection mechanisms such as --owner-of and --changed-parent into functions in the pants --query language.
For now, the "output" would be whatever you get from ./pants --query <...> list, which is lines of text, each specifying a target address. This seems like a very good interface to start with, because the result of --query can then be immediately used by pants tasks without invoking a separate process (which should at least reduce our internal CI time). There may be other outputs we might want, but it seems we can avoid needing a complex output format in favor of adding more of our existing target selection mechanisms to the pants --query language.
TODO
Starting with #6501 (comment), it seems like it would be both useful and fun to merge our target selection options (currently:
--changed-parent,--owner-of, and thefilter,paths?, anddependeesgoals) into a composable interface. One existing example (ish) of this is the bazel query language, although that tries to output graphs, and has its own command-line goal.Rather than making it into its own goal, it seems like making an option
--querywhich wraps our existing target selection logic, and then allowing goals such aslist,compile, ortestto use the selected targets the same way they currently use e.g.--changed-parentseems like a great way to incorporate our current mechanisms, while making the use of multiple selection mechanisms significantly more performant by allowing query composition instead of invoking multiple pants processes, as well as by use of the v2 engine.Another specific and possibly important point from #6501 (comment) is that while composing expressions in the bazel query language is done by nesting function calls, we can consider what should be a strict extension to that language by incorporating the
|operator à lajq. Other extensions to that language would involve incorporating our existing selection mechanisms such as--owner-ofand--changed-parentinto functions in the pants--querylanguage.For now, the "output" would be whatever you get from
./pants --query <...> list, which is lines of text, each specifying a target address. This seems like a very good interface to start with, because the result of--querycan then be immediately used by pants tasks without invoking a separate process (which should at least reduce our internal CI time). There may be other outputs we might want, but it seems we can avoid needing a complex output format in favor of adding more of our existing target selection mechanisms to the pants--querylanguage.TODO
--owner-ofand--changed-parentto be the first supported (single) expressions in a--queryglobal option.--queryfunctions which can also be used in@rules(less important), as per./pants dependeesshould be deprecated in favor of a "root selection" option #6501 (comment).--owner-of,--changed-parent, all of the arguments tofilter, and whatever else comes to mind into--queryfunctions.--queryexpression to allow chaining function calls with|likejq.--query.