-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 support for tidy linting via external tools for non-rust files #112482
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
a044fc4
to
1d05b0d
Compare
*pip_checked = true; | ||
} | ||
|
||
let status = Command::new(py_path).args(["-m", "pip", "install", &bin_vers]).status()?; |
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.
Installing any version could lead to differences between users. What I recommend is:
- Add a
requirements.txt
somewhere in the source tree, pinning the versions of the tools we use (ideally withpip-compile --generate-hashes
from arequirements.in
) - When creating a virtualenv, install the
requirements.txt
file and copy the file itself into the virtualenv - In any future tidy invocation, check if the
requirements.txt
in the source tree matches the one copied into the virtualenv, otherwise discard the whole virtualenv and create a new one from scratch.
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 do like your process and will update to do that so versions aren't hard coded. But what differences are possible as-is? bin_vers
is a pinned version e.g. ruff==0.0.272
, and the version is verified before running https://github.com/rust-lang/rust/blob/1d05b0dbb4ce2e0afa82d63518443ba96aaf7888/src/tools/tidy/src/ext_tool_checks.rs#L248-L251
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.
Before we do a bunch of work with pinning requirements, I think it's useful to take a step back and ask whether we want this checking at all. I'm not convinced I want to put contributors on the hook for fixing lints and formatting in the majority of our Python and shell code. If it's not checked in CI then I'm not sure it adds enough value for us to then take on the burden of maintaining this code and getting PRs trying to fix issues these linters will warn about.
(following up with @Mark-Simulacrum's comment at top level) That of course makes sense. I think it would be pretty reasonable to enforce Enforcement of shellcheck.... there are a lot of errors. Maybe it would make sense to enforce in CI but only error or error+warning levels? I do intend to start a PR to fix at correct the issues of those levels. It is your call for what you do and don't want to enforce, but I am happy to put in the legwork to make that happen. |
All three tools can actually output diffs of their suggested changes - if CI enforcement is a yes, I'll add a way to print those on error when running on GH. |
1d05b0d
to
a57d303
Compare
Just note that when you pin a version of a package, you basically also pin the version of (C)Python, version support sometimes moves fast and it's not always easy to install a set of pinned packages on a different version of Python than the one on which the versions were pinned. |
That is a good point. I think it's a fairly unlikely issue since This patch makes sure it's using python 3.7+ which is supported by both tools (and prefers newer versions), but 3.7 is going EOL in a couple weeks.... |
I think at least for black+ruff it would make sense to enforce them in CI. They both provide hint in the CI output on how to fix them, and if someone changes so much Python code that applying the suggestions get bothersome, they should have a working Python toolchain locally. If we get lots of people complaining about this in a month or so we can reconsider, but this is also a change that's really quick to revert. |
@pietroalbini What value do you see in enforcing formatting for our Python? My sense is that lints may make sense (looking at #112499, there's quite a bit more than I expected, though it's hard for me to gauge severity with my knowledge of Python), but I don't see as much value in formatting the limited set of code. I don't think we've ever had problems with formatting and needing to re-push after X minutes just because you had a slightly different idea of formatting is painful in my experience. I don't think we can expect folks to have Python toolchains (with pip etc.) locally, even if they are modifying a good chunk of Python code. |
318187f
to
44cea52
Compare
This comment has been minimized.
This comment has been minimized.
44cea52
to
d2b5e1f
Compare
This comment has been minimized.
This comment has been minimized.
d2b5e1f
to
ac59754
Compare
This comment has been minimized.
This comment has been minimized.
On one side, having a consistent style across the codebase is good, like we do for Rust. The more important point for me though is being able to run autoformatting in your editor without having to disable it for rust-lang/rust. |
db53f24
to
a35950a
Compare
This comment has been minimized.
This comment has been minimized.
@bors rollup=never |
b48ec03
to
64b2f00
Compare
Thanks @pietroalbini! Feel free to ping me with whatever might be decided at that point I just updated a few things to get this to pass with the latest master so I think I need your |
Looks like bors didn't correct the labels when this got bumped @rustbot ready |
Probably won't let me do this one but we'll try... @rustbot label -S-waiting-on-bors |
64b2f00
to
91590df
Compare
@pietroalbini would you be able to redo your r+? Since you had previously approved, I only needed to reapply the new rustfmt options, and fix a few lints that had happened since #112499 - but no serious changes. |
☔ The latest upstream changes (presumably #113592) made this pull request unmergeable. Please resolve the merge conflicts. |
This change adds the flag `--check-extras` to `tidy`. It accepts a comma separated list of any of the options: - py (test everything applicable for python files) - py:lint (lint python files using `ruff`) - py:fmt (check formatting for python files using `black`) - shell or shell:lint (lint shell files using `shellcheck`) Specific files to check can also be specified via positional args. Examples: - `./x test tidy --check-extras=shell,py` - `./x test tidy --check-extras=py:fmt -- src/bootstrap/bootstrap.py` - `./x test tidy --check-extras=shell -- src/ci/*.sh` - Python formatting can be applied with bless: `./x test tidy --ckeck-extras=py:fmt --bless` `ruff` and `black` need to be installed via pip; this tool manages these within a virtual environment at `build/venv`. `shellcheck` needs to be installed on the system already.
- Remove unneeded imports in 'fuscia-test-runner.py' - Add explicit stacklevel to 'x.py' - Fix mutable types as default args in `bootstrap.py` and `bootstrap_test.py`
91590df
to
9df0f5d
Compare
@bors r+ Sorry for the delay! |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9fa6bdd): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 632.004s -> 632.25s (0.04%) |
Fix python linting errors These were flagged by `ruff`, run using the config in rust-lang/rust#112482
Fix python linting errors These were flagged by `ruff`, run using the config in rust-lang/rust#112482
This change adds the flag
--check-extras
totidy
. It accepts a comma separated list of any of the options:ruff
)black
)shellcheck
)Specific files to check can also be specified via positional args. Examples:
./x test tidy --check-extras=shell,py
./x test tidy --check-extras=py:fmt -- src/bootstrap/bootstrap.py
./x test tidy --check-extras=shell -- src/ci/*.sh
./x test tidy --ckeck-extras=py:fmt --bless
ruff
andblack
need to be installed via pip; this tool manages these within a virtual environment atbuild/venv
.shellcheck
needs to be installed on the system already.This PR doesn't fix any of the errors that show up (I will likely go through those at some point) and it doesn't enforce anything new in CI. Relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Other.20linters.20in.20CI