Replace versioneer with hand-rolled version generation code.

Created by: tomprince

The version of versioneer has an issue that the tarball that is generated on github changes, when the branches and/or tags refering to a commit change. This causes issues for gridsync, which pins the hashes of those tarballs.

In addition to that, versioneer doesn't provide a meaningful revision for untagged commits, when run from a github tarball.

Given that we only ever consume a github tarball as a github archive (except in local development, where the version number is less important), this replaces versioneer with some hand-rolled code specialized to that use case.

The options for pre-existing code to do something similar that I am aware of, setuptools_scm and versioneer, are both python 3 only in their current versions, and neither of them support $Format:%(describe)$ (which was added in git 2.32, which allows to to get the distance from the last tag in an archive.

To get this to work, I've push an annotated tag v0.0 to the repository, pointing at the first commit. (the unreleased git 2.35 drops the requirement for the tag being annotated.

Created by: tomprince

You can test the versioning part by running

pip install https://github.com/PrivateStorageio/ZKAPAuthorizer/archive/pull/274/head.tar.gz

and observing the version number reported by pip when installing.

I don't know how to conclusively test that this fixes the hashing issues, but you can inspect the generated tarballs to see that the new version shouldn't change when branches are updated. If you inspect https://github.com/PrivateStorageio/ZKAPAuthorizer/archive/pull/274/head.tar.gz (in particular src/_zkapauthorizer/_version.py in it), you can observe that the substituted values depend only on the commit, its parents, and any tags pointing to them. This is unlike the current version; if you look at that file in https://github.com/PrivateStorageio/ZKAPAuthorizer/archive/main.tar.gz, you will see

    git_refnames = " (HEAD -> main)"

which can vary, depending on if the commit is the tip of a branch in the repository or not.

The contents of the archive (and the version!) can still change with this patch, if a new tag pointing at this commit or one of its ancestors is pushed, if the tag is closer than the previous tag. But that should be rare enough to not be an issue in practice.

Created by: crwood

Review: Approved

I can't confirm whether this will serve the overarching purpose of providing stability for GitHub-hosted tarballs (as GitHub could always regenerate or otherwise modify archives for reasons unknown to us) but I can confirm that this at least properly generates a version string -- and that the resultant string (of, e.g., 0.0.1083+git.78ffca17494c9278a6de3b0374f40c228e617b33) is more useful than the 0+unknown version that I normally see.

Merged by: tomprince at 2022-01-03 21:45:14 UTC