Proposal: Derive pkg version from git using setuptool_scm
#92
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
remove setup.cfg in favor of pyproject.toml files. this consolidates metadata and allows us to use... setuptools_scm to version all packages. previously a namespace package would contain an _version.py file, w/ __version__ = "x.y.z". this was a little cumbersome, but worse, there was not a good way to determine which version of the code someone was using. setuptools_scm will now automatically create ._version using git tags when the package is installed. additionally, if the installed package is not from a specific tag, setuptools_scm will add metadata to the version including the code's git hash and date of install. this in-theory will vastly improve our ability to reproduce user submitted issues. tags follow the following semantics: ngen.<package-name>/v<x>.<y>.<z> tags that do not follow this format will not be recognized and used by setuptools_scm to create the correct pkg version.
|
Looks like |
|
Moving this into draft. There are still a few things I need to sort out before this is ready for review. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Given that our packages are not published to a public registry (i.e.
PyPI), anyone who uses these packages either installs using a github link via pip or by cloning the repo and installing from a local copy. When issues arise and user submit issues, a common first question is, "what version of the code are you using?" For worse, at this moment, we/users dont have a robust way of answering that question. As it sits, we hardcode the version of a package in a subpackage's_version.pyfile and call it a day. However, as we all know, this does not tell the the whole story unless we were to update_version.pywith every commit to the repo (insanity). To remedy this, this PR introducessetuptool_scm, a build time tool that extracts information fromgitand adds version information to packages including a_version.pyfile, as a build time step to all of our packages. This works when installing from a git link, locally, and locally in edit mode.How does it work?
setuptool_scmuses git tags to determine versions. It searches for the latest git tag and creates a version string based on the tag. See the table of the default version scheme for more information.Given that this repo is effectivity a monorepo, i've chosen to introduce a tagging convention that lets us track subpackage versions using tagging namespaces (i.e.
ngen.<package-name>/v<x>.<y>.<z>). So for example, to cut a release of thengen.configsubpackage, just push an annotated tag likegit tag --annotated "ngen.config/v0.2.5" --message "ngen.config v0.2.5"; git push upstream "ngen.config/v0.2.5".To aide in the transition, ive created tags for all releases of all subpackages and pushed them to the repo. Even if we decide against this, this will be helpful.
related to NOAA-OWP/DMOD#476
Notes
ngen.<package-name>/v<x>.<y>.<z>. Tags that do not follow this format will not be recognized and used bysetuptools_scmto create the correct pkg version.