So, extending <https://pantsbuild.slack.com/archiv...
# development
b
So, extending https://pantsbuild.slack.com/archives/C0D7TNJHL/p1661472615085329 I think there might be a use-case for union-inheritence (or at least, opt-in inheritence member grabbing a la https://github.com/pantsbuild/pants/pull/16646). Looking at
fmt
and
lint
(and the soon to be
fix
, and thinking about targetless formatters/fixers) .
lint
is expected to run: •
Get(LintResults, LintTargetsRequest())
Get(LintResults, LintFilesRequest())
Get(FmtResult, FmtTargetsRequest())
• (future)
Get(FmtResult, FmtFilesRequest())
◦ Assuming BUILD file formatters are just specific file-formatters • (future)
Get(FixResult, FixTargetsRequest())
• (future)
Get(FixResult, FixFilesRequest())
Ideally this is just collapses into two: target-tool-runs and targetless-tool-runs. It's techincally doable today, but formatters and fixers have to register multiple `UnionRule`s for the parent types: ...
Copy code
UnionRule(FmtTargetsRequest, BlackRequest),
        UnionRule(LintTargetsRequest, BlackRequest),
Which isn't ideal. Thoughts?
The implementation sketch looks like:
Copy code
@union
class LintRequest: ...
@union
class FixRequest(LintRequest): ...
# Implementation detail that Fmt classes inherit from Fix classes
@union
class FmtRequest(FixRequest): ...
then in
lint
Copy code
request_types = union_membership.get(LintRequest, include_subclass_members=True)
Plus also some plumbing to convert a
FmtResult
to
LintResult
Copy code
@rule
def convert(r: FmtResult) -> LintResult:
    ...
Then magic
lint
gets to be mostly generic. (We'd still need to support
only
and
--skip-formatters
, etc..., but I think those can be done in other ways)
Actually I might be able to hardcode the "type erasure" rules here too 🤔
Or maybe not...
Copy code
Invalid Get. Because an input type for `...` was annotated with `@union`, the value for that type should be a member of that union.