I recently found out about https://pre-commit.ci, and I'd like to propose we adopt this tool as part of our CI for linting/auto-fixing.
The idea is that this automatically runs
$ pre-commit run --all-files
on each pull request and commits to the corresponding branch to auto-fix errors with pre-commit hooks (black, isort and flynt in our case). I'm reaching out to you because this would have small repercusions on everyone's workflow. Let me try to give a comprehensive description of gains and costs in the following.
what it gets us
a simplification of our CI tooling, namely: - `tests/lint_requirements.txt` - `.github/workflows/style-checks.yaml` - https://github.com/yt-project/slash-command-processor all become useless
`.github/PULL_REQUEST_TEMPLATE.yaml` will also be simplified as all linting items in `PR Checklist` become redundant.
On top of this, new hooks could be seamlessly added in the future without increasing the entry barrier for occasional contributors (as installing pre-commit hooks locally is and remains an opt-in).
what it costs us
- "zero" configuration: the only requirement is `.pre-commit.yaml`, which is already part of the repo. - minor updates to .pre-commit-config.yaml, namely : - bumping black's version (reason: black's `--exclude` flag is overidden by pre-commit's `--all-files`, but more recent versions of black have a `--force-exclude` flag that overcomes this) this will require a new PR to adopt black's latest (minor) updates in code styling - signing up tohttps://pre-commit.ci (free)
what this changes to your workflow
PRs will be automatically fixed by the bot, so you'll either need to occasionally run `git pull` or `git push --force` to account for it. Note that this can be avoided completely by installing pre-commit hooks locally which is and will remain an opt-in, see https://yt-project.org/docs/dev/developing/developing.html#pre-commit-hooks.
Let me know what you think. Take care, and happy new year ! Cheers, Clément