Show gooseBit version in UI

[easybe]

Having the gooseBit version (including Git hash for pre-releases) somewhere in the UI would be very handy.

[b-rowan]

Not sure exactly how to get the git hash integrated into there, this might work, but I assume reading the version should be easy enough. I'll start there.

[easybe]

Personally, I like the “versioning with Git (tags) only” approach. Maybe this could work for us: https://pypi.org/project/poetry-git-version-plugin/

[b-rowan]

Personally, I like the “versioning with Git (tags) only” approach. Maybe this could work for us: https://pypi.org/project/poetry-git-version-plugin/

Just need to figure out how to store that somewhere as part of an action, which might be tough. This should be available to versions even if they're not being run from git.

The other option is we just try to source the git hash and use that, and if there is no git repo we use the project version.

[easybe]

I don’t understand. Either the version is baked by the plugin into the package or retrieved from the repo. In which situation does that not work?

At least that is how the plugin should work IMHO. But, I haven’t looked at it.

[easybe]

OK, I guess there is the situation where someone wants to run the app from a Git checkout and does not have Git installed or a tarball from GitHub. If we want to support those use cases, the plugin won't work.

[easybe]

poetry-dynamic-versioning seems to be the better plugin.

[easybe]

I actually don't really use Poetry. So, if these plugins don't support

. venv/bin/activate
pip install -e .
python -m goosebit

I am not a fan.

Still, I would really like to see versions like 0.3.0+g2b5f4d6 when running an untagged revision.

[easybe]

I gave poetry-dynamic-versioning a quick try (#194) and it seems to work well enough with pip as well. However, there does not seem to be a fallback for when version control is not available. I don't know if that is a tradeoff we can live with.

Personally, I prefer not having to create "bump" commits, pushing a Git tag should be all it takes to create a release.

[b-rowan]

Personally, I prefer not having to create "bump" commits, pushing a Git tag should be all it takes to create a release.

I get what you mean, but not sure how else to do that. AFAIU it's not feasible for a tag to be pushed then the poetry version number updated, so I am ok with the extra step for now.

[easybe]

With poetry-dynamic-versioning the workflow would be like this:

• Push tag
• The packages is built with the version deduced from tag
• The Docker image build installs the package corresponding to the tag
• pyproject.toml is not touched, it contains 0.0.0 as fake version

Would that not work for you?

[b-rowan]

With poetry-dynamic-versioning the workflow would be like this:

• Push tag

• The packages is built with the version deduced from tag

• The Docker image installs the package corresponding to the tag

• pyproject.toml is not touched, it contains 0.0.0 as fake version

Would that not work for you?

This seems fine, let me do some looking and I'll see.