(Short write-up of the `fmt`/`lint` changes, assum...
# development
(Short write-up of the `fmt`/`lint` changes, assuming the tool name is
) `lint.py`: • Plugins register rules using
(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
: a mapping from
key: Any
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
(the key, and a subset of the partition) and returns a
• The rules look like: ◦
PoliteRequest.PartitionRequest -> Partitions
PoliteRequest.SubPartition -> LintResult
`fmt.py`: • Same idea as
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)
👀 1
CC @sparse-lifeguard-95737
the general shape of this does look like my (vague) thoughts of how generic batched testing would work