`./pants fix` <- inspired by the scalafix proje...
# general
l
./pants fix
<- inspired by the scalafix project
1
w
yeaaa, this is very good and general. but one challenge is that it might be too good a name for this usecase… because it does meta-things to the build, we might end up squatting a name that we want to use for things that operate only on existing targets
goals can totally rewrite BUILD files, but when they do, it’s pretty important for them not to invalidate their own work. it’s ok for
fmt
to invalidate the results of
lint
, because they can’t run in parallel in the same run.
…but if a meta-fix was running alongside
scalafix
, you’d get into a situation where you needed to run
./pants fix
multiple times until it stabilized: the first run might create new targets, and then the second run would update those targets, etc.
👍 1
…i.e., you’d have to run it to a fixpoint (no relation!)
maybe that could be baked in…? it’s a bit like how
fmt
feeds the results of consecutive formatters to one another. cc @hundreds-father-404
j
These are excellent points, @witty-crayon-22786. Maybe the goal could provide a "This is what I plan to do." And if you approve, then you order the plan to be done.
👍 1
w
yea, definitely. i added that as a comment on the review. coke
j
TIL that goals can modify
BUILD
files. This means there is a way to apply
black
to them!
h
There is! Although, it's an interesting problem. Changing a BUILD file currently results in a lot of invalidation because we don't know if you added or removed targets, for example I don't think we would want changes to BUILD files on by default. But...what about something like an option
[black].build_files = true
? That could be a really neat feature we could add!
Although, it's an interesting problem
And I think there's also challenges with how it would impact later parts of the run, e.g. if you ran
./pants fmt lint
. Stu has thoughts there. Although, fwict, not very different from the status quo that
fmt
rewrites the world
w
the thrust of this thread is that the “init” goal could be the “meta-fix” that only adjusts your build
(with the exception of this comment: https://pantsbuild.slack.com/archives/C046T6T9U/p1612399381146300?thread_ts=1612398885.144600&amp;cid=C046T6T9U … which is noodling on how you might merge
fmt
with “init”)
j
Yeah! So don't change the files with
fmt
but with a goal that everyone knows modifies
BUILD
files
w
right
👖 1
h
That makes sense! And once we add other languages, it's reasonable to have users who want to autoformat their BUILD files, but don't use Python in general so don't want to activate
pants.backend.python.lint.black
[tailor].autoformat_build_files = true
w
but, thinking about this more…. technically you could tack
BUILD
file formatting onto the end of
fmt
. because while formatting a
BUILD
file would invalidate
fmt
, it would** be a trivial invalidation… i.e., there would not be any need to keep running to a fixpoint
(unlike “init”/tailor, which would make real changes to
BUILD
files)