so in v2, we will almost certainly move away from ...
# development
w
so in v2, we will almost certainly move away from "i tell you what has changed", and towards, "the Graph can quickly recompute some value for you."
what this might look like concretely is something similar to the watchman model:
i connected and ran
./pants list
, and i want to quickly know whether anything used to compute that was invalidated
so it might be emitting a token that identifies the root node
and then very quickly being able to say "has that root changed"?
ftr, i think that an API like this one might be possible and even easy today.
a
ok. that might be really useful for Metals or any IDE which might want to auto-import when a target has changed
and would allow the IDE to avoid using its own file watching heuristics, more importantly
w
and the equivalent for building a pex is rebuilding it, and digesting the pex
and then optionally using this API for low latency if you're doing it in a loop.
a
yes
the user mentioned that they’d prefer to use the target fingerprint or something since they can’t rely on pexes being built reproducibly if the sources haven’t changed
will link the issue
i mentioned to the user that reproducible pex building is i believe also possible
We could hash the PEX file, but then we're at the mercy of pants to produce exactly (bit for bit) the same PEX file with each build. Admittedly, a shared cache probably makes this mostly an academic concern.
w
we did actually spend time to make pex reproducible. it's not perfect, but.
we/Eric
a
yeah
i was wondering whether it was sufficient for their needs here