Use poetry build system, update Python version to ^3.8 to include 3.12+

[darthtrevino]

• Does this PR have a descriptive title that could go in our release notes?
• Does this PR add any new dependencies?
• Does this PR modify any existing APIs?
  • Is the change to the API backwards compatible?
• Have you built the documentation (reference and/or tutorial) and verified the generated documentation is appropriate?

Reference Issues/PRs

What does this implement/fix? Briefly explain your changes.

This overall goal of this PR is to support Python 3.12+. I felt that this was not a safe thing to change without a deterministic dependency management system, so I included Poetry. The makefile scripts have been moved inside pyproject.toml, in addition to the content found in setup.py, setup.cfg, requirements.txt, etc.. More can be done here, but this is a first stepp.

Any other comments?

We'll need to address the publication step and setting a version there. There are tools and plugins we can leverage on the poetry side, but we should also be using the Pypi Trusted Publisher configuration to avoid having to use twine to manually upload the final artifacts.

[bdpedigo]

@darthtrevino just checking if you're all done making changes?

[bdpedigo]

also, wondering if you can describe what the new release process with this system would be. not familiar with poetry dynamic-version

[darthtrevino]

Yep, no more source changes in this PR.

So the poetry-dynamic-version plugin will use git tags to version your artifacts. When you have this plugin installed and run poetry build it will build the wheelfile using a version based on the most recent git tag. If you're on a git tag, it will use that tag's version. If you're on main and you're several commits away from a release tag, it will generate a prerelease version with a hash (e.g. 2.1.0-pre-)

So the normal release flow is like this:

• In a release PR, update the version in pyproject.toml to the new version (e.g. 1.6.0), this is mostly for documentation/development sanity purposes.
• When the release hits main, cut a new release in GitHub.
• The new release will create a tag (e.g. v1.2.0), the workflow will trigger and release a package with the tag version (1.2.0)

You'll probably want to ensure that the publication step will work on prerelease builds before cutting a public release.
Note that this isn't using Twine, you'll need to set up a Trusted Publisher in PyPi, which is way easier: https://docs.pypi.org/trusted-publishers/

[darthtrevino]

You can test this process out locally if you've got the plugin installed - create a new tag on a branch (e.g. v4.0.0) then run poetry build, compare that to poetry build without being on a tag.

[bdpedigo]

thanks @darthtrevino !