Upgrade 0ver to Python 3.13, add GitHub Actions, and other QoL improvements

[MattTheCuber]

Closes #169, closes #185, closes #225, closes #228, and closes #233

Summary

This PR accomplishes several things.

1. It brings the project into compatibility with Python 3.13.
2. It adds GitHub Actions for validation, testing, and upgrading.
3. It revamps projects.yaml providing a number of changes and fixes. See here.
4. It adds the ability to override data automatically retrieved from the GitHub API when using the gh_url key. This allows you to specify the correct first_version if it isn't tagged on GitHub.
5. It adds the ability to specify your GitHub username and GitHub token using command line arguments instead of environment variables. See here.
6. It revamps the projects README.md to provide contributors with a more detailed guide.

After Merge

After merging this PR, @mahmoud will need to

1. Add a GitHub secret and variable to hold the API personal access token and GitHub username for the CI. See the README.md for more information.
2. Make sure the workflow runs properly.

TODO Before Merge

• Release new pip version for Chert @mahmoud
• Figure out publishing the site @mahmoud
• Polish README @MattTheCuber
• Update and check projects.json for validity @MattTheCuber

Original PR questions

So, I thought this wouldn't be too bad, but now I am just really confused. I compiled a list of questions below:

• How does the release process work for this project?
• How is Chert being used? Chert seems to be a problem right now because it requires Python 3.4 (3.13 fails) and can only run on Linux with rsync installed. Not sure the best course of action here...
• What is Travis? It appears to be a CI platform, would it be possible to switch to GitHub Actions?
• What are your thoughts on implementing a linter like Ruff?
• What are your thoughts on implementing a config file as an alternative to environment variables? If yes, do you have a particular way you would like this?

ANSWERS: #227 (comment)

[MattTheCuber]

I'd love to update the README in this PR if I can get a better understanding of the process.

[mahmoud]

Hehe, yeah, apologies for the dearth of documentation. This was an April Fools' joke that got a lot more traction than expected 😅 Nothing we can't fix though! These are good starting questions.

Release process

I'm on Ubuntu 22.04, using Python 3.10 (the default I think).

1. I pull the latest version locally
2. Activate my chert virtualenv. 0ver doesn't use any deps outside of the Python stdlib and whatever chert brings in.
3. I run GH_USER=mahmoud GH_TOKEN=$(cat /path/to/github_token.txt) python tools/gen_projects_json.py in the root directory of the repo.
4. I run chert serve to preview
5. chert publish to upload.

Chert

Chert's a static site generator I use for 0ver, calver, and my blog. I pip install it from the github repo. The PyPI version may be out of date. It definitely runs on Python 3.10 at least. rsync is only necessary for the publish, local rendering and serving have been tested on Mac/Windows in the past.

CI

GitHub Actions all the way. Would ideally love to never speak of Travis again (they got bought by private equity and the rest is history).

Linter

I'd be fine with Ruff, though it's really just one Python file for 0ver. I "lint" the YAML of other projects with a custom command, but that's a little more work.

Config

Which configuration vars were you thinking about? I only use the env vars for github auth. When only dealing with a couple of params, it's often easier that way. Chert itself also has a config, in chert.yaml.

[MattTheCuber]

The linting and config questions were related to the modules in the tools directory which appears to not be in use anymore based on your comment?

[mahmoud]

Well, I do use one script in tools. I only use [gen_projects_json.py](https://github.com/mahmoud/zerover/blob/master/tools/gen_projects_json.py). The other two were used by CI. They can probably be fixed up if we get CI again. Would love CI to keep the star count up to date instead of me having to remember once a month or so.

[MattTheCuber]

Sweet, I got nothing better to do over the holidays XD

[MattTheCuber]

What is custom.py?

[mahmoud]

What is custom.py?

chert feature, gives you hooks to modify posts. here's the relevant chert code. In zerover, it's used to pull in the lists from the JSON files, turn them into the tables that constitute our walls of shame/fame.

[MattTheCuber]

I pip install it from the github repo. The PyPI version may be out of date. It definitely runs on Python 3.10 at least. rsync is only necessary for the publish, local rendering and serving have been tested on Mac/Windows in the past.

I was able to install Chert from the repository. I fixed a couple errors from the newer Python 3.13 version and am working on a problem with the os.symlink call in core.py which doesn't seem to work on Windows.

UPDATE:
mahmoud/chert#4

[MattTheCuber]

@mahmoud Want to take a look at the new workflow and let me know what you think? I would also love to know what to fill out for the chert publish part. I also need to add chert to the requirements.txt file

https://github.com/mahmoud/zerover/pull/227/files#diff-ca6f078365c28ec2fd343babed0771d353dc1d6be7c68928a75032e7841037a1

[MattTheCuber]

Also, there are several pull requests and issues that can be merged and closed.

[MattTheCuber]

Which configuration vars were you thinking about? I only use the env vars for github auth. When only dealing with a couple of params, it's often easier that way. Chert itself also has a config, in chert.yaml.

I only found those 2 and the caching one. I was just thinking that a config file is more cross-compatible because commands like GH_USER=mahmoud GH_TOKEN=$(cat /path/to/github_token.txt) python tools/gen_projects_json.py don't work on Windows.

[MattTheCuber]

A super easy way to use this is python-dotenv.

Simply create a .env file, then at the top of the Python script, call load_dotenv(). Simple as that!

UPDATE:

I added this in the latest commit, lmk what you think.

[MattTheCuber]

Working on a really cool system to add after this PR...

Related to #236

[MattTheCuber]

Lol, I love https://github.com/MaskRay/ccls 's spin on 0ver

[mahmoud]

Lol, I love https://github.com/MaskRay/ccls 's spin on 0ver

Haha, CalVer and 0ver, por que no los d0s?

[mahmoud]

Code looks great! A few comments on the approach, but I think this is getting quite close.

[mahmoud]

Doing a closer read of the CI, I think I spotted some issues.

[mahmoud]

And we're merged! This was awes0me, looking forward to the next!

[mahmoud]

OK knocked out a few bugs and now there's just the workflow / commit back bit that's not happy: https://github.com/mahmoud/zerover/actions/runs/12578454094/job/35057198438

Otherwise, looking good!

[MattTheCuber]

I'll look into this 👍

[mahmoud]

And there it is, like magic: 5ab8308

[mahmoud]

Haha, looks like merging multiple PRs at once exhausts the request limit and fails the parallel actions. A few fixes come to mind:

1. Freeze in the emeritus status projects (write a command to do this), so that if a project is emeritus and has all the necessary keys, we don't fetch any of it from github anymore, even if the gh_url is there.
   • This probably cuts requests in half.
2. Add a flag to only fetch/add projects in the YAML that aren't in the JSON.
   • If this commits back, it's going to conflict, so probably don't commit. Let the nightly job pick it up.
3. Solution 2 + switch to a directory-based approach so every project gets its own little JSON file.
   • I was thinking a directory could work well for avoiding conflicts in the source yaml, too.

Just brainstorming. If any of these appeal, feel free to create an issue/PR.

[MattTheCuber]

Greta ideas! I honestly love all of them. I'll do some thinking and probably do some work in another PR. Can you convert that comment into an issue?