Move all linters to pre-commit.

[sallner]

This is a first attempt to solve #1031. Hopefully the PR will get corrected with the current github action configuration.

I have chosen to use GHA over pre-commit.ci directly, as it is not possible to deactivate the autoupdates of the hooks in pre-commit.ci. The lite version via GHA does no autoupdates at all.

The aim would be to update the hooks only in zopefoundation/meta.

I intentionally did not run the pre-commit hook on my local machine to show the functionality on GHA. This way I also tried to separate the generated code changes with my manual ones.

Open issues/ideas:

• split the PR into many simpler ones, which are reviewable
  • Run isort, autopep8 and flake8 in pre-commit. #1224
  • add docformatter to pre-commit
  • add teyit to pre-commit Add teyit for better test assertions #1226
• use sphinx-lint to lint the rst files, see https://github.com/pytest-dev/pytest-rerunfailures/pull/255/files as an example

[icemac]

Mostly LGTM, just some suggestions.

[icemac]

@dataflake What do you think about these changes?

[dataflake]

Reviewing 260 files with a bunch of changes is insane. I am missing information what those changes are about. Is it all just changing comment formatting?

Secondly, I still don't know what the change in developer experience is. What exactly does this switch to pre-commit do? Does it now force-run stuff on every commit? Locally? Remotely? Does it make changes to my commits that I cannot control? Do I get explicit feedback what changes are made? I have no idea what this really does.

[icemac]

@dataflake wrote:

Reviewing 260 files with a bunch of changes is insane. I am missing information what those changes are about. Is it all just changing comment formatting?

@dataflake I am now going to split this PR into smaller chunks, which are reviewable. The changes are either about formatting or changing the code to a newer style. So the changes should not be dramatic.

Secondly, I still don't know what the change in developer experience is. What exactly does this switch to pre-commit do? Does it now force-run stuff on every commit? Locally? Remotely? Does it make changes to my commits that I cannot control? Do I get explicit feedback what changes are made? I have no idea what this really does.

Let me explain a bit:

• To run pre-commit automatically on commits you can install the pre-commit hook into your repository (by calling pre-commit install), so it runs automatically on each git commit call. But you also can run it manually or rely on GHA to run it for you.

• If pre-commit made any changes to your code, it will not commit the changes automatically. You will have to call git commit again with the changes included. So you in full control of the changes there is nothing done in your name you cannot control.

• If you call git add + git commit instead of git commit -a you will can see the changes pre-commit made via git diff after it said that it made changes.

• If you decide to let GHA run pre-commit for you, the changes it made are visible as a commit in the PR, e. g. afe29e3. This commit is also not assigned to your name but to pre-commit, so it is visible that the bot did the changes.

Was my explanation helpful?

[icemac]

See #1224 as the first step.

[dataflake]

Like I said in #1224, I'd like some way to run those same things that GHA would run manually in my sandbox, and I don't want anything auto-committed.

[dataflake]

Things are looking good. How do we move forward? @sallner mentioned a few other tools that could be integrated into pre-commit like docformatter, teyit or sphinx-lint.

[icemac]

I added the next steps to the description of this PR. Let me first land the PR in config/meta (including to find out what is needed so fixes can be committed by GHA (like in this PR which did not happen in zope.browserpage)), then I'll create individual PRs for the remaining tools.