How am I supposed to configure my linter in VS Code when creating a pull request for cpython?
Autopep8, Ruff & isort are way too strict and I had to turn them off. It seems like only a trailing newline is required.
I would expect autopep8 to be correct. However, a general rule is “don’t touch any code you don’t have to touch” (this goes for basically all open-source projects). This means you shouldn’t run the formamter on the file, but just on your changes. I don’t know how to configure this in VS Code.
For cpython pull requests, turn off all automatic formatting and manually match the style of the code that you’re changing.
Some day, we’ll probably adopt automatic formatting of some variety, but if so it will be done uniformly and not via local configuration.
1 Like
Yeah, that’s precisely what I did, but this workflow still complained:
I have a hard time figuring out what it actually checks, but it seems to require trailing newlines.
Apparently we are using ruff in Lib/test/; see cpython/.pre-commit-config.yaml at main · python/cpython · GitHub. You can activate pre-commit to get the same checks locally.
1 Like
If you have pre-commit installed, running pre-commit run -a locally before submitting your pull request should be sufficient to fix (or at least identify, if they can’t be autofixed) all linting issues on your PR. @Nineteendo, the check for trailing newlines that you’re referring to is this pre-commit hook here: cpython/.pre-commit-config.yaml at 630df37116b1c5b381984c547ef9d23792ceb464 · python/cpython · GitHub (not Ruff).
1 Like
The Ruff config we have for Lib/test only enables a single rule, though; it’s very limited 
cpython/Lib/test/.ruff.toml at main · python/cpython · GitHub.
gh-60283: Check for redefined test names in CI by hugovk · Pull Request #109161 · python/cpython · GitHub is the context for why it was added.
1 Like
I guess I’ll just rely on the workflow: I don’t like to do this manually, and it doesn’t fail frequently.
I think that when we adopt automatic formatting (and sorting imports), this could be applied by the IDE whenever a file is saved.
Well, the nice thing with pre-commit is that it’ll be enforced by Git when you work locally. I would definitely recommend trying pre-commit out. Also, the CI churn saved is worth it alone, IMO.
1 Like
Oh, so that’s why it’s called pre-commit, I thought I had to run this manually. Then I’m fine with using it.
I feel like setting up pre-commit should be at least mentioned here:
Maybe we could even let bedevere-app mention this when lint fails? Then it should happen only once per contributor (except for accepting review suggestions).
2 Likes