-
-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lint-v2 implementation for python with black, and script to be used in pre-commit hook #8553
Add lint-v2 implementation for python with black, and script to be used in pre-commit hook #8553
Conversation
This is a prerequisite for ultimately adding a pre-commit hook that behaves similarly to our isort pre-commit hook (warns the user and lets them actually modify their code once they are ready for it) * Create a top level `lint-v2` rule; * Implement `lint_with_black` which implements that rule for python; * Deduplicate `lint_with_black` with `fmt_with_black`; * Make use of `FallibleExecuteProcessRequest` to make lint output less spammy.
Now we introduced a lint goal which takes the same kind of targets as an input, it makes sense to use a more general name.
The issue that was link before isn't obviously related to the issue. The actual problem is `TargetAdaptor.sources` throwing an exception.
This PR is an aggregate of #8452, #8454 and #8490 I wanted to merge them in order to preserve a bit more git history, but I haven't been able to merge even a single PR in the last 3 weeks due to a mix of CI flakyness and broken master. Reducing these PRs to one should allow me to merge them earlier (as soon as I get one single green CI). All the code in previous PRs was already reviewed and the only unaddressed comments were higher level discussions about v2 rules on #8490 (which I don't think required action on this particular PR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i have just done a quick browse since all of these changes were already reviewed in the other 3 PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Please open a followup PR to address the nits.
@@ -53,6 +54,17 @@ def elapsed_time() -> Tuple[int, int]: | |||
return elapsed_seconds // 60, elapsed_seconds % 60 | |||
|
|||
|
|||
def git_merge_base() -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should follow up on this, I think: this script should not have different behaviour from our other linters, and so the fact that this function didn't exist before might indicate that it doesn't need to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is basically a duplicate of the one in common.sh
. Eric was of the opinion that it was worth having these utilities straight in python for the python scripts. In the (very) long run we can dedup by removing all the shell scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Note that I originally wrote this script as a bash script, but python was deemed preferable as that's the direction we're trending towards for these kind of scripts)
|
||
|
||
@rule | ||
def fmt_with_black( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: fmt
and lint
don't need to actually use the --check
flag: they can be completely identical, and just check whether the output snapshot matches. Maybe using --check
would be slightly faster for a single run? But if you assume that the next thing someone will do after lint
fails is run fmt
, the impact of running exactly the same process is that it would be cached, and the two runs overall would be faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--check
makes black output prettier diagnostics (N files would have been formatted
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also render those diagnostics, but in a more general way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. Possibly a bit more work, but I get why it would be desirable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this discussion is currently about black, but it's a general point that we may want to get right across the variety of formatters and linters that the v2 engine will eventually support. (Brief summary from private chat with @stuhood)
@@ -27,7 +21,7 @@ class FmtResult: | |||
|
|||
|
|||
@union | |||
class FmtTarget: | |||
class TargetWithSources: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This no longer seems to mean this. Please loop back to reference #4535 here in a TODO. And given how generally it's being treated, it should likely exist in some other file, near the target API itself.
Problem
In the near future, we will want to add a pre-commit hook that helps us remember to automatically format our code with black.
Currently, the version of black that's integrated in pants will always modify the user's code, which may not be desirable in a pre_commit hook situation.
Solution
Result
See integration tests for examples: User can call ./pants lint-v2 .... The command will fail if the files would be formatted, but won't rewrite the files.