https://pantsbuild.org/ logo
#general
Title
# general
n

nice-park-16693

03/16/2023, 8:57 AM
Does anyone have any tips for integrating pants formatting into pre-commit checks? Let's take
black
as an example -- I would like to be able to run
black
with the same config and versions through pre-commit as I do when I execute
pants fmt
so that the results are consistent, but I don't want to config these in two places. So far I've tried: • just run
black
via pre-commit, ignoring pants. This is fairly trivial but it needs me to write a version number in
.pre-commit-config.yaml
as well as in
pants.toml
, and that's slightly annoying because those can get out of sync • change pre-commit to run
plz fmt
instead of using the
black
plugin directly. This avoids the need to duplicate config, but it has the downside that now pre-commit doesn't format build files or things that pants doesn't "know about", like stuff under
3rdparty/
. Any pointers from someone who has trodden this path before? Same question applies to lint and check.
r

ripe-scooter-10665

03/16/2023, 9:09 AM
I use the second option (just running pants fmt | fix | lint | check directly so that the version and setup is consistent to running manually but I’d also be interested to see if anyone has any better solutions
b

broad-processor-92400

03/16/2023, 10:36 AM
We have a do-it-all alias that runs the equivalent of
pants tailor update-build-files fmt lint check ::
. I imagine this could be invoked from a pre commit hook. I think it’s possible to have BUILD files defining targets in
3rdparty
too. Another option for them might be having the normal pre commit plug-in run on only the non-pants directories (and, even if the configs are different, at least each file has a single source of truth, either pants or pre-commit$.
2 Views