Add git status to Ribasim CLI wrapper version

[evetion]

Fixes #1475

ribasim -V
ribasim 2024.8.0-68-g333e2ac-dirty

What's a bit ugly is that the Cargo.toml is now in a dirty state, but for CI builds that doesn't matter.

[evetion]

We could do a similar thing to the Project.toml of the Julia core (as that is printed on running).

[visr]

This looks nice. Do I understand the format right? ribasim 2024.8.0-68-g333e2ac-dirty means 68 commits after git tag 2024.8.0, last commit g333e2ac, and dirty means you have local uncommitted changes. And for a release it is still just 2024.8.0?

What's a bit ugly is that the Cargo.toml is now in a dirty state, but for CI builds that doesn't matter.

Does this also mean that -dirty is always added? Or just that the act of building always makes Cargo.toml dirty?

What I like now is that we always have uniform version numbers. By applying this enhancement to the CLI version number, we don't have that anymore for non-release builds.

The version number now exists in these places: #1462
This test still works with this change:

Ribasim/build/tests/test_cli.py

Line 33 in 333e2ac

assert ribasim.__version__ in result.stdout

This version number is still the latest release:

Ribasim/core/src/libribasim.jl

Lines 176 to 181 in 333e2ac

	Base.@ccallable function get_version(version::Cstring)::Cint
	@try_c_uninitialized begin
	ribasim_version = Ribasim.pkgversion(Ribasim)
	unsafe_write_to_cstring!(version, string(ribasim_version))
	end
	end

This format does seem to somewhat work with Julia's VersionNumber:

julia> dump(VersionNumber("2024.8.0-68-g333e2ac-dirty"))
VersionNumber
  major: UInt32 0x000007e8
  minor: UInt32 0x00000008
  patch: UInt32 0x00000000
  prerelease: Tuple{String}
    1: String "68-g333e2ac-dirty"
  build: Tuple{} ()

julia> Ribasim.pkgversion(Ribasim)
v"2024.8.0-68-g333e2ac-dirty"

Though if it is easier we could also stop setting the Ribasim version in Project.toml, since we don't use SemVer anyway. We could just set it to 1 and use a constant String in the code.

The clap docs also refer to https://crates.io/crates/shadow-rs for these kinds of things, perhaps that is less hacky? Don't know how / if this is worth doing for python.

[visr]

See my comment, but this does seem like a nice improvement to help prevent confusion.

[visr]

Also, shouldn't we bump the version number to 2024.9.0 directly after tagging 2024.8.0? To clarify it is a pre-release of 2024.9.0.

[evetion]

This looks nice. Do I understand the format right? ribasim 2024.8.0-68-g333e2ac-dirty means 68 commits after git tag 2024.8.0, last commit g333e2ac, and dirty means you have local uncommitted changes. And for a release it is still just 2024.8.0?

Yes.

git describe --tags
v2024.8.0-71-g6b97f732
# Full commit information
git show v2024.8.0-71-g6b97f732

Does this also mean that -dirty is always added? Or just that the act of building always makes Cargo.toml dirty?

The latter.

This format does seem to somewhat work with Julia's VersionNumber:

I've indeed made sure it works for both Rust and Julia's version semantics (both use semver).

What I like now is that we always have uniform version numbers. By applying this enhancement to the CLI version number, we don't have that anymore for non-release builds.

Agreed, but that caused our confusion when comparing our builds locally. Non-release builds should only be for testing and comparing, and having this information really helps.

Though if it is easier we could also stop setting the Ribasim version in Project.toml, since we don't use SemVer anyway. We could just set it to 1 and use a constant String in the code.

When one set versions programmatically on release, I have seen versions like 0.0.0 in code as placeholder. Not sure if that change makes sense at the moment, but I do think we have too many version strings now.

The clap docs also refer to crates.io/crates/shadow-rs for these kinds of things, perhaps that is less hacky? Don't know how / if this is worth doing for python.

That's a nice crate, it's the external version of our metadata code in Julia. However, I think ideally we have the version in the Julia source code, and other parts (Rust/Python) access it from there. Julia itself has a shellscript to bake the (git) versions into the Base code.

Also, shouldn't we bump the version number to 2024.9.0 directly after tagging 2024.8.0? To clarify it is a pre-release of 2024.9.0.

That would depend on our release branches/management (never patch releases?). For now our approach seems to work fine though?

[visr]

If we switch to directly updating the version number post-release, will this approach still work?

[evetion]

If we switch to directly updating the version number post-release, will this approach still work?

No, as it currently uses the git tag. Neither will the information that's now been made in add_metadata be correct. We could change it to use the Julia version instead, and suffix it.

But I'm hesitant to make such changes here, let's discuss design in a new issue first.

[visr]

Sounds good, feel free to merge.