Tool boilerplate reduction

[kaos]

Is your feature request related to a problem? Please describe. Adding new tools takes way too much effort.

Describe the solution you'd like For standard tools (like, pip install tool-x && tool-x --version) it should be enough to provide the bare minimum in terms of what requirements it has and goals it supports.

Describe alternatives you've considered

• Generate the boilerplate code from some input DSL.
• Support using the input DSL as-is during runtime.
• Something else. Haven't allocated that many braincells on this yet.

EDIT: The code_quality_tool may be a good alternative for tools that fit the fix fmt lint bill of goals. (as pointed out by @sureshjoshi)

Additional context For context, adding a SQL tool for linting and formatting requires an unhealthy amount of boilerplate (#20854) (granted, almost 1.3k lines of that is for the lockfile, but there's still plenty of boilerplate):

[sureshjoshi]

Isn't this what code_quality_tool is for?

But yes, I've agreed with this position for a while :)

[kaos]

Isn't this what code_quality_tool is for?

Ah, you're absolutely right. I forgot about that one. Perhaps revisit #20854 to see if it can be implemented using that..? (cc @grihabor)

[grihabor]

I thought code_quality_tool is primarily intended for adhoc usage, so it won't show good help, it doesn't support things like ConfigFilesRequest, install_from_resolve, etc.

[kaos]

Good point. (I've not looked much at it, so I have no good sense of its current limitations)

I thought code_quality_tool is primarily intended for adhoc usage

That may perhaps be the current state of it is best suited for..

so it won't show good help, it doesn't support things like ConfigFilesRequest, install_from_resolve, etc.

.. yet. I think we'd like to build upon it to make it suitable for less adhoc use as well. But if it's not feature complete enough for the sqlfluff tool today, let's proceed with the work in #20854 as is for now :)

cc @gauthamnair could perhaps fill in more details here..

[gauthamnair]

@kaos @grihabor @sureshjoshi I just took a look at the Sql PR. What code_quality_tool could have done (in the form introduced in https://github.com/pantsbuild/pants/pull/20135 ) is:

• Provide lint/fix/fmt on *.sql files not targets. It only works against files and so does not have the ability to do things like skip in targets or pull in dependencies of source files. The only way to include/exclude is by file globs.
• the tool can be any runnable (adhoc-tool compatible). So it can be sqlfluff installed from any particular resolve. You can definitely control the resolve, the same as you would for a python source file or requirement.
• the tool can accept one or more config file targets, but the user has to configure that explicitly themselves via Targets.
• the pants help you get for a code quality tool is very minimal.

CodeQualityTool is for when you have a runnable and just want to lint/fmt/fix with it. It is intended for use by users rather than by plugin authors. The sql support added in #20854 would not be improved by it. In fact it is unclear how to provide a plugin through code quality tool.

For another look at trying to reduce the boilerplate that plugin authors face, you can also check out what @lilatomic was piloting back in https://github.com/pantsbuild/pants/pull/16412

For a kind of long-form treatise on the matter there is https://docs.google.com/presentation/d/15P0YdoX1T4fX0DpNzwwXxP1bMVZqUZ_GB9Jkn3rQwRQ/edit#slide=id.p

[kaos]

Thanks for the details @gauthamnair, that all makes sense.