Enable pre-commit autoupdates

[bswck]

The current pre-commit config depends on https://github.com/astral-sh/ruff-pre-commit/releases/v0.1.8 while the newest version is https://github.com/astral-sh/ruff-pre-commit/releases/v0.2.0 (changelog). While we can manually update these dependencies, there is some room for automation.

Considerable options are:

• enabling https://pre-commit.ci service for this repo,
• adopting renovate,
• waiting as long as Support pre-commit dependabot/dependabot-core#1524 is open with the possibility to supply a temporary workflow.

[bswck]

@jaraco I saw that older Ruff (from pre-commit) started conflicting with the newer Ruff (from tox) when I worked on jaraco.classes. What do you think about these options? Do you maybe have some other ideas?

[jaraco]

Another option is simply to drop pre-commit. I've been reluctant to adopt pre-commit because of its bias for repeatability over sustainability. I'm personally disinvested in pre-commit, and I don't use it personally in my workflows, but I'm okay with allowing it if it benefits others and adds negligible toil to the project(s). That is, an occasional PR in skeleton is fine.

I'm open to the other options too. I'd like to see any option implemented in a sustainable way (infrequent pull requests centralized in skeleton would be fine).

[hugovk]

infrequent pull requests

You can configure it to run quarterly instead of weekly:

ci:
  autoupdate_schedule: quarterly

https://github.com/termcolor/termcolor/blob/7143ed6ae03c1b4686cf21d87b25275df06d5c0e/.pre-commit-config.yaml#L59-L60

https://pre-commit.ci/#configuration-autoupdate_schedule

(And as mentioned, another option is to use Renovate, but I don't think that can fix PRs. https://docs.renovatebot.com/modules/manager/pre-commit/)

[Avasam]

Concerning the pre-commit tool as a whole. I personally only enjoy it for its CI autofixes. Which isn't even happening for skeleton-based projects (for various reasons Jason already mentioned). I also highly dislike blocking or slow local commit hooks.

It might be worth considering a GitHub action like https://github.com/EndBug/add-and-commit or https://github.com/stefanzweifel/git-auto-commit-action . I'm personally looking for something like this since I'm also hitting pre-commit limitations with dprint and eslint (on top of the version lock annoyance), but haven't yet tested or vetted any. At work I wrote our own Azure DevOps extension for it.

Edit: if the configs are being kept solely "to offer a git hook command for those that use it", maybe instead you could offer a tox env command to autofix everything and let the dev decide how they wanna add it as a git hook ? (manually, pre-commit tool, husky, etc.)