https://pantsbuild.org/ logo
Join SlackCommunities
Powered by
Need some opinions on <https://github.com/pantsbui...
# development
b
Need some opinions on https://github.com/pantsbuild/pants/pull/16926 Specifically, the question of "Whether to add the 
args
options to tools which don't take argv _today_" Pros of adding it: ā€¢ Future-proof. The user who is using Pants today can upgrade the version of the tool to one that does take 
argv
, and can now pass args ā—¦ Otherwise the user would have to either fork the support in-repo, or upstream the change and wait and upgrade Pants šŸ˜ž ā€¢ Consistency across all tool subsystems. They all have 
args
option Cons of adding it: ā€¢ Funky UI for users of versions that don't take an argv. They try and pass something and the tool goes boom
I'm in the pros category. I'd rather us not make too many assumptions of the underlying tools' future.
h
I'm in the cons camp. I don't think we should have an option that is going to result in user errors when the user tries using it a) how often do we really think a tool doesn't have argv support and then decides they want to add it? b) argv semantics are sometimes complex. there are several cases where we process the argv option and ban certain values, or warn if you set it. each tool should intentionally consider its relationship with argv
b
For b) it's the same story IMO users could upgrade to a version pants can't make assumptions about. I agree with the fact that we should consider the relationship today, but not that we can make assumptions about the future. For a) I'd ask a similar question. What else does someone expect to happen when passing arguments through pants to a tool that doesn't support them? What even argument would they use?
There's another angle to this as well. If we decoupled plugin releases from core pants releases upgrades would be less painful. For now that's off the table
f
Whether a tool should have an "args" pass-through option is really a function of how the tool is ordinarily invoked.
for example, if you take Google Java Format, most of its options are related to check mode versus reformat etc. -- so we only expose the one user-tunable parameter as an option
šŸ‘ 1
having pass-through args would be confusing for users
āž• 1
for many tool, Pants needs to invoke the tool in a certain way in order to get the expected reformat in place behavior.
pass-through args can interfere with those tool invocation depending on what the user sets
šŸ‘ 1
scalafmt is another example
all fmt configuration is done through 
.scalafmt.conf
files and not command-line parameters
it would be confusing to expose an 
args
in that case for scalafmt plugin
The user who is using Pants today can upgrade the version of the tool to one that does take 
argv
, and can now pass args
args
are only necessary if the user can actually take advantage of them. If there is a future version of the tool that could make use of them, I submit that then and only then should Pants be updated to add that option. Moreover, the Pants rule for the tool would need to check the version and error if args were passed when an older version of the tool was configured. Thus, the Pants rule would need to be aware of versioning in any case.
šŸ’Æ 1
h
I submit that then and only then should Pants be updated to add that option.
Strong +1. And if users aren't willing to wait for a new Pants version, they can use an in-repo plugin. In the future, maybe we do your proposal to decouple backends from core Pants versions also
Open in Slack
PreviousNext
Powered by