Fix pre-commit issues

[kurtmckee]

This PR addresses the following items:

• Remove a duplicate pre-commit hook (check-toml)
• Run pre-commit run --all and fix all identified items
• Run pre-commit autoupdate to update all hook versions

---

I strongly recommend visiting pre-commit.ci and enabling it for this repository. The service will check incoming PRs, add commits to fix hook violations if possible (for example, changes identified by black or ruff), and will post PRs to keep pre-commit hooks up-to-date.

[DimitriPapadopoulos]

Fixes #2958.

[DimitriPapadopoulos]

I strongly recommend visiting pre-commit.ci and enabling it for this repository. The service will check incoming PRs, add commits to fix hook violations if possible (for example, changes identified by black or ruff), and will post PRs to keep pre-commit hooks up-to-date.

Isn't this suggestion a duplicate of #2961?

[larsoner]

Okay I added pre-commit.ci as a GitHub app. Someone feel free to add the YAML and hopefully it just works :)

[kurtmckee]

@DimitriPapadopoulos

I strongly recommend visiting pre-commit.ci and enabling it for this repository. The service will check incoming PRs, add commits to fix hook violations if possible (for example, changes identified by black or ruff), and will post PRs to keep pre-commit hooks up-to-date.

Isn't this suggestion a duplicate of #2961?

No. The author of #2961 appears to be suggesting that someone remove the .github/workflows/{black,mypy,ruff}.yaml files and add something like this to a job in a new "linting" workflow or to an existing workflow file:

run: |
    pip install pre-commit
    pre-commit run --all

I'm instead suggesting to use the pre-commit.ci service to do the same thing -- and more -- automatically.

---

@larsoner

Someone feel free to add the YAML and hopefully it just works

If pre-commit.ci is enabled for the repository there is no need to add a YAML file. The service will automatically begin interacting with new PRs and submitting PRs to update hook versions (example) on a weekly (IIRC?) basis. The existing .pre-commit-config.yaml file is all that's needed.

Note that, if the service is enabled, then the {black,mypy,ruff}.yaml workflows can simply be deleted as pre-commit.ci will not only run those linters (because they're configured in .pre-commit-config.yaml), but the service will add commits to PRs that black/ruff create diffs for (example).

[larsoner]

Note that, if the service is enabled, then the {black,mypy,ruff}.yaml workflows can simply be deleted as pre-commit.ci will not only run those linters (because they're configured in .pre-commit-config.yaml), but the service will add commits to PRs that black/ruff create diffs for (example).

Want to go ahead and delete them in this PR then?

[larsoner]

... pre-commit.ci appears to be running in #2968. Looks like there are a couple of errors that I'll fix over there

[kurtmckee]

It seems out-of-scope for this PR, though, so I'll submit a separate PR (and confirm that pre-commit.ci runs against the PR!). 👍

[larsoner]

Mypy CI is unhappy

[kurtmckee]

That's correct, but mypy in pre-commit is happy. They share the same version (v1.4.1) but don't share the same configuration. 😢

How do you want me to proceed?

[kurtmckee]

(I have a preference to remove the mypy hook from pre-commit and standardize its configuration in a config file that mypy will pick up in local runs and in CI, but I'll defer to the codespell team to make the call.)

[larsoner]

How do you want me to proceed?

It seems like the cleanest solution would be to get the mypy config used both places. But in practice it seems like we would want it to run using the correct config in pre-commit and then just use that locally and in CIs (via pre-commit.ci)

[kurtmckee]

The mypy issues should be resolved.

• I've tested on mypy running on Python 3.7 and Python 3.11 (found discrepancies resolved by using a mypy-recognized sys.version_info conditional instead of a try/except block)
• I've tested locally with make mypy and pre-commit run --all-files mypy
• pre-commit.ci discovered that an autogenerated _version file didn't exist and gave its own unique unknown import complaint

[larsoner]

Thanks @kurtmckee , feel free to work on the CI changes if you're still up for it!