has the topic of having the build graph be informed by the target dependency graph ever been discussed? i.e by marking a certain target dependent on another target, it will ensure that the dependency will be built before the dependent?

Hey JP! What do you mean by build graph here? "build" could mean a couple things, e.g. the

package

goal, compiling code, or even more generic like running tests

yeah great question

This is for a plugin, right? You can order things in a way that makes sense for your domain in the plugin by structuring your

await Get()

differently For example, rather than

MultiGet()

, you can use a

for

loop like this https://github.com/pantsbuild/pants/blob/4e23ed4962ec88b2dd93f36097b151d90a1ebc5e/src/python/pants/backend/python/lint/python_fmt.py#L36-L52 Usually, you want that parallelism, but up to you decide. Or, do:

part1 = await Get(A, B, b)
part2 = await Get(X, Y, z)

yeah i get that. this is currently achievable by something like:

deps = await MultiGet(Get(Targets, DependenciesRequest(target.get(Dependencies()) for target in targets)

await MultiGet(Get(Results, target) for target in deps if target.has_fields([])

but the semantics of the dependency field seems like it might be useful to push that up to the build graph, obviously there may be architectural challenges to that

There's less of a notion of a unified build graph than with the v1 engine, where it was a first-class concept. The rules API allows that graph to fit the domain of your plugin For example, for autoformatters, we solely care about the files. For flake8, we need direct deps. For MyPy, we need transitive deps. Those all have different notions of a build graph

ah understood

To be clear, you can also recurse. In the example of JVM compilation, where one of the inputs of the "compile A.java into a classfile" is "the classfiles obtained by compiling A's dependencies", you'd simply

MultiGet

classfiles for all the deps, even if that involves recursively calling the same rule.