Hook is nondeterministic, can we hardcode the current EOL versions instead?

[GideonBear]

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.10

I 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)?

[sco1]

I don't understand what the issue is with the example, 3.10 will be EOL a year from now. Can you elaborate?

[GideonBear]

I don't understand what the issue is with the example, 3.10 will be EOL a year from now. Can you elaborate?

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]

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]

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.

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.

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.

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 entire premise of the hook is date-based, so it needs to be an input here.

The "date" is hardcoded into the hook, in the form of the list of EOL versions. pre-commit autoupdate will bump pre-commit-python-eol, and with it, the "date".

This is similar to what pyproject-fmt does with the classifiers (although that is manually)

[sco1]

Ah, I understand what you mean now. I think this would be reasonable as a second hook, the data is already present anyways.

[GideonBear]

Also, it looks like the hook only runs when pyproject.toml is changed, and thus only errors when the date is past EOL and pyproject.toml was modified. My solution solves this because pre-commit runs the hook on all files (only pyproject.toml) again when the version is changed.