Repository navigation
Hook is nondeterministic, can we hardcode the current EOL versions instead? #8
Description
Hi! The hook is currently nondeterministic based on the current date. An example:
(#7 applied)
$ pre-commit run -a
Check supported Python EOL...............................................Passed
$ faketime -f "+1y" pre-commit run -a
Check supported Python EOL...............................................Failed
- hook id: check-eol
- exit code: 1
pyproject.toml: EOL Python support found: 3.10I like the approach pyproject-fmt takes, where they bump the latest Python version manually, and release a new version, causing an autofix on an autoupdate to add the new classifier. Are you open to doing something similar here (but fully automatic)?
Activity
sco1 commentedon Dec 5, 2025
I don't understand what the issue is with the example, 3.10 will be EOL a year from now. Can you elaborate?
GideonBear commentedon Dec 5, 2025
Pre-commit hooks are supposed to be deterministic. Currently, you can make a commit/PR and have pre-commit fail, not because of anything you did wrong in the commit, but because of the date. This forces you to either fix it in your (unrelated) commit, or commit a fix in a different branch and then rebase everything you're working on.
(This is even worse when a lot of PRs are open, every commit after that date will fail CI and force a rebase.)
sco1 commentedon Dec 5, 2025
The entire premise of the hook is date-based, so it needs to be an input here. I can understand that this might introduce pain but the function of the hook I think is pretty clear. I wrote this to solve a desire I had, and while I'm ok with inflicting this pain on myself I totally understand if other users are not.
I did not explore a fixer because I think changing supported Python versions should be an intentional task, as there are often changes to be made beyond bumping things in the project specification. Autofix would still fail the hook so I don't see how that solves this particular pain.
GideonBear commentedon Dec 5, 2025
Oh I totally understand it if you want to keep it this way, I just thought I would at least propose it before implementing it for myself only. IMO there's a better way.
Sorry if my issue was unclear, the proposal is not to include an autofix.
I want to remove all dependency on the current date from the hook (which will make it deterministic), and hardcode (in a JSON file) current EOL versions, instead of a list of all versions and their EOL dates. An automated workflow will generate those from the current date, and release a new version if there is any change.
In other words:
The "date" is hardcoded into the hook, in the form of the list of EOL versions.
pre-commit autoupdatewill bumppre-commit-python-eol, and with it, the "date".This is similar to what
pyproject-fmtdoes with the classifiers (although that is manually)sco1 commentedon Dec 5, 2025
Ah, I understand what you mean now. I think this would be reasonable as a second hook, the data is already present anyways.
GideonBear commentedon Dec 5, 2025
Also, it looks like the hook only runs when
pyproject.tomlis changed, and thus only errors when the date is past EOL andpyproject.tomlwas modified. My solution solves this becausepre-commitruns the hook on all files (onlypyproject.toml) again when the version is changed.Merge pull request #9 from GideonBear/main