Python 3.4 Support (Officially) Dropped
My goal for this release was NOT to drop support for any of the previously supported versions. However, 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. Since I am no longer easily able to test against it, I can't verify that `pycallnumber` still works on 3.4, so I'm officially considering it dropped.
Python 3.8, 3.9, 3.10, 3.11 Support Added
All tests now pass against modern Python versions. Supported versions now include 2.7, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11.
Past Functionality Remains Stable
Besides dropping support for Python 3.4, no user-facing functionality has been changed for this release. All changes involve the package structure and supporting configuration / tooling.
Begin Moving 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 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` now contains canonical metadata. Metadata variables in the root `__init__.py` are inferred from package metadata using `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 it generates a sensible [PEP 440](https://peps.python.org/pep-0440/)-compliant version string for us, 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](https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/) is generally 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.
Tox Configuration and General CI/CD Methods Improved
The tox configuration is now 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 still needed to build a universal wheel for Python 2.)
Although not exactly pertinent to the final built package, 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.
Upcoming Deprecations
Be aware that the next release, v1.0.0, will drop support for Python 2.7, 3.5, and 3.6! Only current Python versions (3.7+) will be supported.