Can I expect format-lint parity for tools such as

black

and

isort

? In other words, are there

lint

violations for these tools that don’t have

fmt

equivalents that can be auto-resolved? Second question, are there performance benefits to be gained by excluding tools from linting e.g.

pants lint --lint-only=isort

(no

black

) that have already been run with

pants fmt

? Or are these violation check results reused between

lint

and

fmt

and

fix

?

For both

black

and

isort

it looks like there is only a format rule - this is the same rule that’s run as part of the

lint

goal: https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/lint/black/rules.py#L111 https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/lint/isort/rules.py#L65 So whether you run

fmt

or

lint

with these tools, it’s the same command being run underneath

Great. Do you know how much reuse of results happens if both

pants fmt

and

pants lint

are being run for these tools?

Not sure about that - from unscientific testing on my local repo it does appear that the tools are run twice

If the command and inputs are the same, the results should be cached.

> If the command and inputs are the same, the results should be cached. In this case, I’m asking about the results of a tool e.g.

black

being cached and shared between

pants lint

and

pants fmt

? Unless that’s what you mean when you say “inputs are the same”?

yea,

lint

and

fmt

doesn't come into play, but the command line and input files, env vars etc to run

black

.

Gotcha, thanks for that. So for my second question ^, would that mean there are minimal performance benefits to be gained by excluding tools from

pants lint

that are already being run previously by

pants fmt

?

yes, I'd say so

Ah, yes, pretend I said

lint

then `fmt`… Thanks for this, clears it up for me.

cool