pantsbuild #general

Channels

welcome

github-notifications

announce

bored-art-40741

01/27/2016, 11:41 PM

One is the graph of goals, and the edges are product dependencies

rough-minister-58256

01/27/2016, 11:41 PM

yeah. tasks are the implementation of goals, essentially.

bored-art-40741

01/27/2016, 11:42 PM

A goal runs. Within that goal there are some tasks, and they run in the order they were installed. Each can do whatever it wants to the target graph in play. In particular, each task can produce some products which are then accessible to downstream tasks

bored-art-40741

01/27/2016, 11:42 PM

Frequently these products are the fundamental units that are cached, too

rough-minister-58256

01/27/2016, 11:42 PM

./pants compile java_target invokes the java-specific compilation task against the given java target

bored-art-40741

01/27/2016, 11:42 PM

Now, all of these tasks express the products they need and the products they provide in lifecycle methods

bored-art-40741

01/27/2016, 11:43 PM

So before anything is ever actually run, pants looks at the goal you ran and schedules all the goals that need to run in the reverse topological order of the tasks, based on product edges

bored-art-40741

01/27/2016, 11:43 PM

This is in contrast to the target graph, which simply models code dependencies between targets

bored-art-40741

01/27/2016, 11:43 PM

We really need, like, a video or something showing this

better-park-26723

01/27/2016, 11:44 PM

I don't quite get it. When you say there's a "graph of goals," I'm thinking "yeah, the

test

goal depends on the

compile

goal" at the highest level, but no actual product dependencies are in that graph

bored-art-40741

01/27/2016, 11:44 PM

It's somewhat straight forward once you visualize a simple example

better-park-26723

01/27/2016, 11:44 PM

It's a very small graph

bored-art-40741

01/27/2016, 11:44 PM

There really are literal product dependencies

bored-art-40741

01/27/2016, 11:44 PM

There are explicitly annotated edges

bored-art-40741

01/27/2016, 11:44 PM

And goals are actually scheduled based on those edges

better-park-26723

01/27/2016, 11:44 PM

Because there are, what, a few dozen goals, and some of them interdepend on each other as goals, but that's the entire graph of goals

bored-art-40741

01/27/2016, 11:44 PM

Correct, it's not a large graph

better-park-26723

01/27/2016, 11:45 PM

Sure, but in my mind, the product dependencies are in the "target graph" only, not in a "goal graph"

bored-art-40741

01/27/2016, 11:45 PM

But for example, if you don't need a goal's products to satisfy your own goal, you don't schedule that goal at all

bored-art-40741

01/27/2016, 11:45 PM

That is incorrect

better-park-26723

01/27/2016, 11:45 PM

So when you say "there's a graph of goals and the edges are product dependencies" that confuses me

bored-art-40741

01/27/2016, 11:45 PM

product here is, by definition, a thing produced by a task

rough-minister-58256

01/27/2016, 11:45 PM

the ‘goal graph’ is essentially just how tasks interoperate

bored-art-40741

01/27/2016, 11:45 PM

Let's use a concrete example

bored-art-40741

01/27/2016, 11:46 PM

I'll talk about two products, which are edges in this graph

rough-minister-58256

01/27/2016, 11:46 PM

they declare their needs to other tasks so when they’re executed either implicitly or explicitly, they cooperate to produce combined outputs

bored-art-40741

01/27/2016, 11:46 PM

compile_classpath

and

runtime_classpath

bored-art-40741

01/27/2016, 11:46 PM

Let's say you run the goal

test

on some target graph. The target graph is immaterial here.

better-park-26723

01/27/2016, 11:46 PM

wait, I guess we didn't define a "product" but I expected you to name two jars, e.g.

foo.jar

and

bar.jar

better-park-26723

01/27/2016, 11:46 PM

I didn't expect you to name two classpaths