For V2 `Goal` options, `fingerprint` is irrelevant...
# development
h
For V2
Goal
options,
fingerprint
is irrelevant, right? That’s only used by V1 caching logic?
a
hmmmmmmm
if
Goal
is an Optionable, then perhaps not
great question
one way to test this would be to run something with
--loop
and see whether changing an option causes invalidation
but that could be done like by changing pants.ini? that sounds iffy
unclear
figuring out what contributes to the hash of the goal’s Options class sounds like a good way to investigate
w
to answer the original question: options are 100% accounted for in a `@rule`'s identity/fingerprint currently, yes. it's eq/hash.
👍 1
and "fingerprinting" as we think about it in v1 only occurs in v2 on an ExecuteProcessRequest basis, in that we have a cache for those.
👍 1