(Short write-up of the `fmt`/`lint` changes, assuming the tool name is

Polite

) `lint.py`: • Plugins register rules using

*PoliteRequest.registration_rules()

(there are multiple unions being registered) • Plugins define 2 rules* (*future PR will provide a "default" implementation of the first rule if opted-into) ◦ A "partitioner" rule. This takes all the specs FieldSets (for targets) / files (for target-less), and returns

Partitions

: a mapping from

key: Any

to

elements: tuple[T, ...]

. (Note the elements can by anything) Most tools have an implementation of "if skip, return empty. Otherwise return one partition of all the inputs". Some plugins do actual partitioning though, and those get to do interesting thing. This is also an opportunity to do expensive work once. ◦ A "runner" rule. This rule takes a

SubPartition

(the key, and a subset of the partition) and returns a

LintResult

• The rules look like: ◦

PoliteRequest.PartitionRequest -> Partitions

◦

PoliteRequest.SubPartition -> LintResult

`fmt.py`: • Same idea as

lint.py

with one change: the partition elements are filepaths for both target-aware tools and targetless tools • The snapshot is retrieved in the "runner" rule by doing

await PoliteRequest.SubPartition.get_snapshot(request)

the general shape of this does look like my (vague) thoughts of how generic batched testing would work