Use dynamic versioning to single-source version from git tags

[jongbinjung]

Does this address #383 ?

Example local install:

$ env/bin/python
>>> import h3
>>> h3.__version__
'4.1.0b4.dev0+g6d9a5fc.d20241011'

and then with a tag:

$ git tag v4.1.0b4
$ env/bin/pip install .
...
$ env/bin/python
>>> import h3; h3.__version__
'4.1.0b4'

Currently using the default versioning scheme; but configurable.

Wasn't sure what didn't work last time (in #378)

[jongbinjung]

Not sure what these failing unit tests are ....

[github-actions]

Coverage after merging jb/dynamic-version into master will be

99.44%

Coverage Report for Changed Files

File	Stmts	Branches	Funcs	Lines	Uncovered Lines

[github-actions]

Coverage after merging jb/dynamic-version into master will be

99.44%

Coverage Report for Changed Files

File	Stmts	Branches	Funcs	Lines	Uncovered Lines

[jongbinjung]

Not sure what these failing unit tests are ....

OK, figured out it was because Github Action workflows only do a shallow fetch; but the "single source" of version with the PR becomes the git history ...

I've tried a couple things to just pull the git tags, but they all failed. Checked out a some other repositories that deploy via Github actions (prefect, pandas), and looks like they all do a full fetch.

[github-actions]

Coverage after merging jb/dynamic-version into master will be

99.44%

Coverage Report for Changed Files

File	Stmts	Branches	Funcs	Lines	Uncovered Lines

[ajfriend]

Oh, this is slightly different from what I was thinking. I simply wanted to define the version in either pyproject.toml or h3.__version__, and have the other read it. I had accomplished (one direction of) it with

h3-py/src/h3/_version.py

Lines 1 to 3 in 121314a

	from importlib import metadata
	__version__ = metadata.version(__package__ or __name__)

and I guess I forgot to close the ticket.

This is cool tho. I do really like the '4.1.0b4.dev0+g6d9a5fc.d20241011' hash for development. However, I do also like having the version explicitly in the code somewhere as opposed to a tag. (But I suppose a tag is a true single source of truth...) Is that an option?

But maybe I just need to get used to this :) What do other folks think? @isaacbrodsky @nrabinowitz @dfellis

[jongbinjung]

Oh, this is slightly different from what I was thinking. I simply wanted to define the version in either pyproject.toml or h3.__version__, and have the other read it. I had accomplished (one direction of) it with

h3-py/src/h3/_version.py

Lines 1 to 3 in 121314a

	from importlib import metadata
	__version__ = metadata.version(__package__ or __name__)

and I guess I forgot to close the ticket.
This is cool tho. I do really like the '4.1.0b4.dev0+g6d9a5fc.d20241011' hash for development. However, I do also like having the version explicitly in the code somewhere as opposed to a tag. (But I suppose a tag is a true single source of truth...) Is that an option?

But maybe I just need to get used to this :) What do other folks think? @isaacbrodsky @nrabinowitz @dfellis

I see. The only way I can think of for having a tag be source of truth and also have the "current" version be available somewhere explicitly would be to have some janky job run at tag creation, that writes some change to master? ... but maybe I just lack imagination.

The main benefit of using tags, imo, is that you can cut a release without having that one odd PR just to bump the version in-code 😅 (e.g., via Github's Release UI)—but I can also see how that might not be necessarily desirable.

[ajfriend]

The main benefit of using tags, imo, is that you can cut a release without having that one odd PR just to bump the version in-code 😅 (e.g., via Github's Release UI)—but I can also see how that might not be necessarily desirable.

We'd still usually need one for the changelog, I think.

[ajfriend]

Thanks for looking into this, but like I said above, I think I got most of what I wanted working previously, and I don't mind the extra PR for a release.

[ajfriend]

Closing for now, but maybe we'll revisit in the future.