This PR implements versioning using setuptools_scm, resolving issue #25 (lack of good version numbering). This is similar to, but simpler than, PINT's use of Versioneer. I had been looking into using setuptools_scm for a different project and remembered that we had never settled the versioning issue for PINT Pal, so I decided to make this PR.
With this in place, you can get the version number at run time as either pint_pal.version or pint_pal.__version__. This version number is based on the tags in git -- setuptools_scm searches back through the git history for the most recent tagged commit, and builds the version based on that. If the current commit is the tagged one, it just uses the tag as the version number, and otherwise it tries to guess the next version number and adds .dev{distance}+g{hash} to the end of it, based on the distance from the tagged commit and the current commit hash. For example, the current version reports as 0.1.1.dev16+g950bd5b.
rossjjennings
commented
1 year ago
This PR implements versioning using
setuptools_scm, resolving issue #25 (lack of good version numbering). This is similar to, but simpler than, PINT's use of Versioneer. I had been looking into usingsetuptools_scmfor a different project and remembered that we had never settled the versioning issue for PINT Pal, so I decided to make this PR.With this in place, you can get the version number at run time as either
pint_pal.versionorpint_pal.__version__. This version number is based on the tags in git --setuptools_scmsearches back through the git history for the most recent tagged commit, and builds the version based on that. If the current commit is the tagged one, it just uses the tag as the version number, and otherwise it tries to guess the next version number and adds.dev{distance}+g{hash}to the end of it, based on the distance from the tagged commit and the current commit hash. For example, the current version reports as0.1.1.dev16+g950bd5b.