if a node has a stable identity because it’s based on a small Param, re-requesting that exact node is quicker, because we can use cleaning and dirtying

but “large” Params (such as the OptionsBootstrapper) tend to be less stable… there are more ways that they can change

and the effect of using the OptionsBootstrapper (effectively “the whole env and args”) as a Param is that any change to that large object represents a brand new node, which cannot be cleaned

it’s a spectrum: what is “large” exactly? but the gut check on

Specs

is: if i ran

./pants test x

and then

./pants test y

, would i want those to be considered “the same run”?

no, probably not.

would i want

./pants test x -- -k some_test

to be the same run?

yes, probably. just with slightly different options.

and “same run” isn’t quite accurate: it’s really, “same node”. this is a decision made on a node-by-node basis all the way down the Graph:

as a Param, the

Specs

don’t actually go that deep in the graph: take a look at the visualization of the graph, and you can see which portion the

Specs

create the identity/memoization key for

ie, only nodes in the graph that indicate

for Specs

are actually dependent on the specs.