We currently want the following to work, I think: ...
# development
We currently want the following to work, I think:
./pants fmt test some:target
Right now in v1 I think it does, and in v2 it doesn’t -
will operate on the original sources before formatting.
I don't think that this is true. Writing files to the workspace will invalidate them.
...and if it doesn't, it could/should, eagerly.
I believe that if you happen to be using pantsd, this is true. And if you’re not, it isn’t.
(And if you are using pantsd, you rely on a race condition, but regardless, with invalidations set up, the result is probably doing the work twice, which is not great)
Well, that's the "eagerly" part. The call to materialize could invalidate eagerly. It's what we do in TestBase for files written via the
Still feels kind of hacky to me 😞
When we sketched the design for this (ages ago: I think in one of your first visits to SF?) we came up with roughly this design. I think the fact that it relies on invalidation "between" goals is a bit odd, but I think the fact that we've isolated mutation to console_rule makes it fairly reasonable.
Mutation anywhere else in the graph would definitely be sketchy, and I hope that we can continue to avoid that. cc @hundreds-breakfast-49010, @hundreds-father-404
👍 1