Fully leaned into the pyproject.toml setup to modernize build via hatch. This centralizes the project dependencies and derives package versioning directly from git tags. Intermediate packages built from commits after the latest tag (e.g., 0.2.0) will have an extra long string, e.g., 0.2.1.dev178+g16cfc3e.d20231223 where the version is a guess at the next version and the hash gives reference to the commit. This means that developers bump versions entirely by tagging a new version with git (or more likely by drafting a new release on the GitHub release page).
Removed setup.py.
TOML does not support adding keyed entries, so creating layered build environments of default, docs, test, and dev as we used to with setup.py is laborious and repetitive with pyproject.toml. We have simplified the list to be default (key dependencies), test (minimal necessary for test-suite), and dev (covering everything needed to build the docs and actively develop the package).
pyproject.tomlsetup to modernize build via hatch. This centralizes the project dependencies and derives package versioning directly from git tags. Intermediate packages built from commits after the latest tag (e.g.,0.2.0) will have an extra long string, e.g.,0.2.1.dev178+g16cfc3e.d20231223where the version is a guess at the next version and the hash gives reference to the commit. This means that developers bump versions entirely by tagging a new version with git (or more likely by drafting a new release on the GitHub release page).setup.py.docs,test, anddevas we used to withsetup.pyis laborious and repetitive withpyproject.toml. We have simplified the list to be default (key dependencies),test(minimal necessary for test-suite), anddev(covering everything needed to build the docs and actively develop the package).