We run linters and formatters via pants as part of...
# general
l
We run linters and formatters via pants as part of our git pre-commit hooks and I have found a behavior I don't understand. When the only file changes is a BUILD file, pants will try a bunch of other files (maybe ones owned by that file?). Is that expected?
w
yea, that’s expected. change detection is file level, rather than target level currently.
we can’t know whether some, all, or none of the target definitions in the BUILD file changed
l
hmm ok. I think we will have to try to filter these out then
w
do you use 111, or larger BUILD files?
l
not sure what you mean by 111?
w
hm, challenging to link to it apparently, but: the “Tip: one BUILD file per directory” callout in https://www.pantsbuild.org/docs/targets
l
yeah we mostly do that
w
PXL_20211111_204202651_2.jpg
(i had always assumed that the name came from google, so it was funny to see Pants cited as the origin in a book about Google)
l
ha that's funny
yeah we are mostly 111 but there are some variances there
w
anywho. i wouldn’t recommend skipping BUILD file changes in `lint`… would break adding/removing of
skip_*
flags, for example
l
yeah but lint and fmt don't update or lint BUILD files, right?
you have to run update-build-files for that?
w
no. but if you have edited a BUILD file, you might need to re-lint the files it owns (see above re: skip flags, or other settings like interpreter constraints)
l
ah yes
w
i.e. if you’ve edited the BUILD file and changed which version of python to lint with