Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

<@U053HNE90>: that doesn't break the model. it's just annoying.

the bugs we're experiencing are due to the invalidation not being transitive

but it should definitely be possible to hash inputs... was wrong about that part, sorry

I disagree that that is the problem.  The issue is that ivy resolution is producing a fingerprint for a _subgraph_, but then individual elements in that subgraph are being fingerprinted by, say, jvm compile

For the product in question, say compile_classpath, specifically the jars

But really, when you ask for the jars for a given target, you really need to qualify that in terms of the _subgraph_ that target is with respect to

<@U053HNE90>: that would be fine if the fingerprint chosen for those targets was transitive

"wait, how did you come up with that fingerprint?" "doesn't matter! deal with it."

Unfortunately it will cause massive cache thrash, for exactly that reason

why? 3rdparty doesn't change that rapidly

Though I will say that's much more desirable than hashing input products

<@U06A03HV1>: I'm imagining jvm compile's FP strategy being invalidated by something irrelevant, like tool bootstrap or something

So maybe being able to request transitive invalidation via product names actually is a baby step in the direction that the engine is supposed to go

Provided we start by _opting in_ to this I think it would be an interesting direction

products should be annotated with a hash of the FP strategy of the task that produced the product

well, also, it means that any change in the ivy inputs would invalidate all compiles.

well, not quite. only some of the ivy outputs will be on your classpath

But they could have _all_ been affected by each other

alright, i see what you're getting at here.

In particular, if your `compile_classpath` entries were all with respect to the _subgraph_ being compiled, then you would get cache stability if the change in 3rdparty/BUILD happened to not leak into the subgraph you're working

However you of course end up with the opposite problem here: there are so many subgraphs that you will rarely get cache hits

right. in master, that's what we get by hashing products.

Yeah.  Hashing products is the middle ground here, but I claim that it's a bad path to go down, and it should be forbidden in the new engine