Begin modernizing the package

[jthomale]

This is the first step in modernizing the pycallnumber project, at least in terms of what Python versions are supported and the packaging setup. It will be the v0.2.0 release.

Ultimately the goal is to get to v1.0.0, in which we will move everything to a fully pyproject.toml-based setup using setuptools. But that will require Python 3.7 or greater. Because I've neglected this project for so long, I wanted an intermediate release that brings in support for Python versions up to 3.11 while still supporting as many previous versions as possible. I don't want to pull the rug out from anyone who is actively using pycallnumber with an older Python version, if I can help it. (Even though versions below 3.7 are out of date.)

Drops Python 3.4 Support (Officially)

That said — unfortunately, I can no longer get Python 3.4 to compile on any of my development machines, since it doesn't work with openssl 1.1, so I am no longer easily able to test against it. Although pycallnumber may still work with Python 3.4, I can't verify this, so I'm considering it officially dropped with v0.2.0.

Adds Python 3.8, 3.9, 3.10, 3.11 Support

All tests pass against the most recent Python versions.

Past Functionality Remains Stable

The v0.2.0 release will not contain any changes to user-facing functionality. All changes are to the package structure and supporting configuration / tooling.

Moves Toward Modern Packaging Setup

pyproject.toml and setup.cfg

Eventually I want to use pyproject.toml as the single-source-of-truth for all package metadata and configuration. With Python 3.7 and above, this is possible; with earlier versions, it is not, since the required versions of the build tools (setuptools etc.) don't support it. For now, I've implemented what I can in pyproject.toml and moved most everything else into setup.cfg. (A completely barebones setup.py still exists, as well, for compatibility.)

The setup.cfg contains canonical metadata. Metadata variables in the root __init__.py are now inferred from package metadata via importlib.metadata (or importlib_metadata for Python 3.7 and earlier).

setuptools_scm

For builds, setuptools_scm now handles versioning. This lets us set the version using git tags, and a sensible PEP 440-compliant version string is generated, even for non-tagged commits. It also ensures that the full contents of the repository are included in the sdist without requiring a MANIFEST.in file.

src Directory Layout

Previously pycallnumber used a flat layout, but a src layout seems a bit better for packages. From now on we'll assume that you have to install the package (even if as an editable version) before running tests. This means we no longer need the context.py file we previously used to facilitate package imports in tests.

Improves CI/CD: Tox and Github Actions

The tox configuration is more robust:

• New test environments allow testing against the oldest and latest dependencies for a particular Python version.
• New environment for building the package lets us do both the build and twine checks via tox.
• New environments for testing the built package allow us to test the build against all supported Python versions. (This is probably overkill, but it helped me catch that I needed to build a universal wheel for Python 2.)

CI/CD is now done via GitHub Actions (using the aforementioned tox environments):

• Travis-CI is no longer used.
• Tests against all supported Python versions plus linters run on each push to the repository.
• Building and publishing to Test PyPI and live PyPI happen when appropriate tags are pushed.
  • Pre-release tags publish to Test PyPI only.
  • Release tags publish to Test PyPI and then to live PyPI.
  • Builds are tested against all supported Python versions, and all "publish" steps are dependent on tests passing. If any part of the build/publish workflow fails, subsequent steps do not happen.