Where should BUILD file formatters/fixers + deprecations fixer live?

[thejcannon]

Currently we have pants.backend.build_files.fmt.<tool> which makes sense in isolation.

However we're adding the deprecations fixers, which today operate solely on BUILD files, but will likely include a pants.toml fixer in the near future.

Which begs the question, where do opt-in metadata-y things belong?

[thejcannon]

My vote is pants.backend.project_info.<goal>. It would accompany other metadata-y goals like list and peek.

[thejcannon]

This is about where the plugins live. The core code will live in core.

[Eric-Arellano]

I'm fine with pants.backend.project_info.fmt.{buildfier,black,yapf}. The only other idea I have is pants.backend.pants_metadata.fmt.{buildifier,black,yapf}, and I don't have a strong reason to prefer one over the other.

[thejcannon]

Ah here's a can-kicking idea. Keep the build file relevant stuff where it is.
When it's time to add a fixer for pants.toml we find it a different home.

And we can have a "meta" that registers both (and maybe more)

[Eric-Arellano]

Yeah, pants.backend.pants_config_fixers or something

[kaos]

I'm not sure pants.backend.project_info.fmt.black is very intuitive. What does that backend bring? Sure I know black, but what project info is it operating on?
I think pants.backend.pants_metadata.* has the same issue in being rather vague what it actually refers to, esp if there are a whole set of different tools in there.

I think I'm leaning towards being open to having many backends (the implementations may be organized differently/together etc) but I don't see a big issue with having pants.backends.build_files.fmt.<tool> and then later adding pants.backends.pants_config.fix.<tool> etc.. that is, have descriptive names for the backends in what the are intended to operate on. If there's overlap we only need to manage the entry points into it so when enabled for a certain set of subjects we can distinguish that when invoked.

In summary, my point I think is to not try to map the implementation 1-1 to the backend naming scheme as these two are not tightly related. Compare for instance with how we've organized the code for the experimental backends as a good example of this.

[cognifloyd]

#17289 (reply in thread)

@kaos had a very good point about making the backend more descriptive. So, I vote:

• Keep build file formatters at pants.backends.build_files.fmt.<tool>
• Plan on adding pants.toml specific fixers in something like pants.backends.pants_config.fix.<tool>

I think pants_config is generic enough to include fixers that touch both pants.toml and BUILD files (eg remove a deprecated option from pants.toml and update the affected targets at once).

The BUILD formatters, however will always be specific to BUILD files, so it's helpful to call that out in the backend name, so I think those should still stay under pants.backends.build_files even after we add fixers under pants.backends.pants_config.

[Eric-Arellano]

I like this. Thanks @kaos and @cognifloyd !

@thejcannon sounds good? Should we close this out? Meaning 2.14 is unblocked

[thejcannon]

Yup! I'm good 👍