Quality-of-life suggestions for release, CI, semantic versioning, etc.

[ziatdinovmax]

Discussed in #56

^{Originally posted by matthewcarbone October 4, 2023}
@ziatdinovmax I have a couple of suggestions for your consideration:

• Pool all setup protocol into pyproject.toml. PEP 621 began the transition of Python setup to the "non-python" pyproject file. In GPax, the setup.py file is not necessary. We can pool all build instructions into the pyproject.toml file.
• CI code can be slightly refactored for clarity.
• Similarly, I have developed a procedure for on-the-fly semantic versioning from tags, similar to the old versioneer.py method, but my method is a few lines and relies on dunamai to grab the current HEAD's tag. I use this combined with "API-key-free" publishing to PyPI, my CI procedure, and GH environments to securely publish any new tagged release. The environment configuration requires manual confirmation before any release, in case you were worried about over-automation causing unintended things to happen. EDIT: there is a better way to do this using hatchling. See here.
• Implement dependabot for automatic version bumps, and version-lock all dependencies. I think this is just good practice to ensure your code works even if a dependency releases an update that should be backwards compatible, but isn't. Example of that here.

The most recent example I have of all of this can be found here, with a slightly less recent example here.

I am more than happy to implement these QOL changes.

[ziatdinovmax]

@matthewcarbone - I converted it back to issue so that we can keep better track of it

[ziatdinovmax]

@matthewcarbone have you had a chance to start implementing any of these?

[matthewcarbone]

@ziatdinovmax I'm sorry I missed this. No I haven't unfortunately. Been bogged down with other projects and stuff. I will do my best to get to it as soon as I can 👍