https://pantsbuild.org/ logo
#development
Title
# development
w

witty-crayon-22786

01/15/2022, 12:25 AM
i had a minor false-start with https://github.com/pantsbuild/pants/issues/13462 this afternoon, in that i started on adapting all formatters to return
FmtResults
(similar to
LintResults
, which allows linters to internally partition themselves), as that looked like a good alignment that would allow formatters to batch themselves using the explicit
BatchProcess
API that i sketched on the ticket.
but looking at it more, i think that that puts too much on the formatters in the common case.
so now i’m thinking about executing the batching in the
fmt
goal itself
and that got me thinking again about having the `lint`/`fmt` goals automatically partition based on
FieldSet
values
…slightly orthogonal actually. but i guess my main point is: formatters or linters needing to return batches of results means that they are internally doing partitioning which we might be able to do outside.
f

fast-nail-55400

01/15/2022, 12:40 AM
how would this interact with the partitioning by config file done by the scalafmt rules?
👍 1
w

witty-crayon-22786

01/15/2022, 12:42 AM
i don’t think that it would be powerful enough to replace that, since it’s based on more than just the fields of the targets. but i could imagine the backends having optional partitioning rules
…or having a computed
ScalafmtConfigField
to generalize it…
h

hundreds-father-404

01/15/2022, 1:05 AM
I'm curious if we could have a plugin hook where you can do custom batching else do the default, perhaps. But not clear to me how to handle if you want your new batching at the same time as existing batching
f

fast-nail-55400

01/15/2022, 12:26 PM
or have the core fmt rules provide a default batching implementation that individual fmt rules can use like a library
(i.e., avoid a “framework” like setup of fmt rules)
w

witty-crayon-22786

01/15/2022, 7:53 PM
Batching by computed/AsyncFields seems like a potentially powerful generalization