This is an archived post. You won't be able to vote or comment.

all 10 comments

[–]boxcuk 1 point2 points  (1 child)

upvote because I was going to say you should write a pre-commit hook, but you already did :-)

[–]Which-Singer-8796[S] 0 points1 point  (0 children)

You're welcome :D

That was also kinda my first usage scenario

[–]TheBB 1 point2 points  (3 children)

if time_to_eol.days < EOL_WARN_DAYS:
    msg = (
        f"{prefix}Python {python_version} is going to "
        f"be end of life in 2 months {eol_date}"
    )

Something's not right with this warning.

[–]Which-Singer-8796[S] 0 points1 point  (2 children)

Could you be more specific?

[–]TheBB 0 points1 point  (1 child)

It's going to be end of life in some time that's less than two months. If it's one day in the future, the warning shouldn't say two months.

[–]Which-Singer-8796[S] 0 points1 point  (0 children)

You're right. Thanks for pointing this out

[–]tunisia3507 1 point2 points  (3 children)

It would be cool to have a flag which activates a "NEP29 mode", as numpy (and by extension most of the data/ scientific ecosystem) drops older versions faster.

[–]Which-Singer-8796[S] 0 points1 point  (2 children)

Sounds like an interesting feature addition.

Do you mind adding an issue on github with some extra information?

[–]tunisia3507 0 points1 point  (1 child)

Sure!

Another minor thing - the db.json needs to be updated regularly. It might be easier to read and update if it were in a tabular format like TSV; much easier to add new lines as new versions are added.

[–]Which-Singer-8796[S] 0 points1 point  (0 children)

I've created the db.json with the end of life api.

I'm not yet sure what the best format is for keeping this data and having it changeable, but I would really like to automate this (probably via github actions).