We currently want the following to work, I think: ...
# development
a
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 -
test
will operate on the original sources before formatting.
w
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.
a
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)
w
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
self.create_file
api
a
Still feels kind of hacky to me 😞
w
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