feat: Add check-eol-cached hook

[GideonBear]

Closes #8

Example:

$ 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

$ nano .pre-commit-config.yaml
# Changed `check-eol` -> `check-eol-cached`
$ pre-commit run -a
Check supported Python EOL (cached)......................................Passed
$ faketime -f "+1y" pre-commit run -a
Check supported Python EOL (cached)......................................Passed

Changes:

• Create a pull request instead of opening an issue because it bugged me, can revert
• Split up getting EOL versions so it can be reused by bump_cache.py
• Add --cached flag that uses a cached list of EOL versions the status of the release instead of relying on the time
• Adds the new cache to bump_cache.py and generate the initial one.

TODO:

• Add tests
• Add automatic version publishing if desired

What do you think?

[GideonBear]

Added tests, all new code is covered

[sco1]

Thanks for this! I have only been able to do a quick scan & will try to take a look sometime this week.

A couple things at a glance:

• Please revert the changes to the CRON workflow. Actual EOL dates have never been on the first of the month, scheduling for mid-month was a hopeful hedge that I could catch the actual end date and not have to keep checking after the first week. Then 3.10 ended up being the end of the month but what can you do lol. I'm happy with the issue workflow as it's something I do in a few other places; my personal preference is to try and minimize 3rd party Action usage as much as I can.
• Please document the new hook in the README

A bit more broadly, I don't think there's really a reason to carry around a second cache file that's the same as what's already present just with less fields per release. There's never going to be a particularly large amount of data so I'd rather just pull the necessary information from the already existing cache.

[GideonBear]

Thanks for this! I have only been able to do a quick scan & will try to take a look sometime this week.

A couple things at a glance:

• Please revert the changes to the CRON workflow. Actual EOL dates have never been on the first of the month, scheduling for mid-month was a hopeful hedge that I could catch the actual end date and not have to keep checking after the first week. Then 3.10 ended up being the end of the month but what can you do lol. I'm happy with the issue workflow as it's something I do in a few other places; my personal preference is to try and minimize 3rd party Action usage as much as I can.

Fair! (btw, I think gh pr create is also a thing, EDIT: it looks like that doesn't create a branch so it requires a bit more work)

• Please document the new hook in the README

Forgot that!

A bit more broadly, I don't think there's really a reason to carry around a second cache file that's the same as what's already present just with less fields per release. There's never going to be a particularly large amount of data so I'd rather just pull the necessary information from the already existing cache.

Makes sense, I didn't think about that. How about including a cached_eol: bool inside each of the versions?

[sco1]

How about including a cached_eol: bool inside each of the versions?

I think using the already existing status field should be sufficient.

[GideonBear]

How about including a cached_eol: bool inside each of the versions?

I think using the already existing status field should be sufficient.

Ah, of course.

[GideonBear]

Done, that was much simpler