Repository navigation
Enable pre-commit autoupdates #109
Description
Activity
@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?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).
Reacted by Avasaminfrequent pull requests
You can configure it to run quarterly instead of weekly:
ci: autoupdate_schedule: quarterly
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/)
Concerning the
pre-committool 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.)
I also recently found this free (for open source repos) GitHub app: https://autofix.ci/
It comes with protection against infinite push loops. And looks easier to configure than the actions i posted above, which requires dealing with PAT and doesn't offer protections against unstable autofixes loops.Reacted by Bartosz Sławeckiif 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.)
That sounds fine by me.
tox -e autofixmaybe?I also recently found this free (for open source repos) GitHub app: https://autofix.ci/
I'm liking this. If it obviates my need for repetitive script aliases, I'll be even more impressed. I wonder, does it only work for pull requests, or could it work for pushes directly to main also (not a problem if not)?
I recently learned of the existence of https://pre-commit.ci/lite which is more or less equivalent to https://autofix.ci/ and was started at about the same time. So I'd recommend using either of those as they are free on public repos.
Relevant comment from the autofix.ci author aboutpre-commit.ci/lite: autofix-ci/action#8 (comment)pypa/setuptools#5042 (comment)
I understand pre-commit (the tool) can be useful to some devs to install git pre-commit hooks. But considering we don't use it on the CI, we should really consider just making it run a "tox autofix" command to avoid having to duplicate versions here.
Then if we want CI autofixes, https://autofix.ci/ and https://pre-commit.ci/lite both do more or less the same job (pushes any local changes during a CI run)
At that point,
.pre-commit-config.yamlwould only be provided out of convenience for those who enjoy pre-commit hooks and don,t want to manually setup a hook to run said "tox autofix" command.
That sounds fine by me.
tox -e autofixmaybe?Pretty much yeah
I wonder, does it only work for pull requests, or could it work for pushes directly to main also (not a problem if not)?
Their own demo shows it running on main push: https://autofix.ci/setup
I started using it in https://github.com/Toufool/AutoSplit/blob/e731cb5cc9c885fcfc64869056bc9bb944dc3250/.github/workflows/autofix.yml (link to workflow file), I like it so far.
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: