When a published gem using GVB is used inside another repo it crashes runtime.

[RoyWarps]

I maintain a number of tools which manage builds. These tools are versioned using GVB and these tools are run inside another repo to perform a number of tasks.
To avoid using the git tags from the repo in which the published gem is being run the production code uses GVB.gem_version to make sure the version is retrieved from the gemspec and not the git tag.
However during requiring of git_version_bump version.rb https://github.com/mpalmer/git-version-bump/blob/d07b7a7623b65315bd0d893ab218e36ac1423c5c/lib/git-version-bump/version.rb still performs a call to GVB.version which will use the git tags.
In some cases the format of the git tags is wrong resulting in a crash as shown below. In other cases the format may be correct but it will show the version of that tag in that particular repo and not the actual version of the gem being run.

/var/workspace/branch_name/.gem/gems/git-version-bump-0.18.0/lib/git-version-bump.rb:49:in `major_version': sync (part of "sync.tag.1234.1234") is not a numeric version component.  Abandon ship! (ArgumentError)
	from /var/workspace/branch_name/.gem/gems/git-version-bump-0.18.0/lib/git-version-bump/version.rb:3:in `<module:GitVersionBump>'
	from /var/workspace/branch_name/.gem/gems/git-version-bump-0.18.0/lib/git-version-bump/version.rb:1:in `<top (required)>'
	from /var/workspace/branch_name/.gem/gems/git-version-bump-0.18.0/lib/git-version-bump.rb:357:in `require'
	from /var/workspace/branch_name/.gem/gems/git-version-bump-0.18.0/lib/git-version-bump.rb:357:in `<top (required)>'
	from /var/workspace/branch_name/lib/super_build_tool/command.rb:5:in `require'
	from /var/workspace/branch_name/lib/super_build_tool/command.rb:5:in `<top (required)>'
	from /var/workspace/branch_name/lib/super_build_tool.rb:2:in `require'
	from /var/workspace/branch_name/lib/super_build_tool.rb:2:in `<top (required)>'
	from /var/workspace/branch_name/bin/super_build_tool:6:in `require'
	from /var/workspace/branch_name/bin/super_build_tool:6:in `<main>'

Why are the constants in version.rb being populated require time?
I had a look but I was unable to find instance inside the GVB library where these constants are being used.
The way these constants are being defined during requiring can also cause them to be redefined if the gem is required multiple times, resulting in warnings.

[mpalmer]

Curiously, I got tripped up on GVB::VERSION myself, just recently. 'Tis the season, apparently...

The constants in version.rb get populated at require time because they're constants, and thus need to be given a constant value. However, I've learnt much since I originally wrote that code, and I can "simulate" a constant just by giving a method an uppercase name (I know, right!) and abusing const_missing a little, so I can (and I think I will) modify version.rb to use that approach, instead.

As for git-version-bump getting a version tag from the wrong place (the gem it's being loaded from, rather than itself), I'll have to build a local test case and figure out exactly what's going on, but I'll figure it out and get a fix out at some point.

[RoyWarps]

As for git-version-bump getting a version tag from the wrong place (the gem it's being loaded from, rather than itself), I'll have to build a local test case and figure out exactly what's going on, but I'll figure it out and get a fix out at some point.

For clarification, the issue of the wrong version being returned happens when the gem is run inside another git repo. That is probably a rather rare use case. We run gems inside another workspace so GVB can successfully execute the git command but is of course not aware that it is talking to a git repo that is not the repo of the calling gem.
Though that issue can be circomvented by using GVB.gem_version.

[mpalmer]

Yes, I think I've figured out what's going on -- GVB is always checking "are we running in a git repo?" and using whatever comes back from the git repo, rather than using the gem version. That'll involve changing some assumptions in the codebase, and may even be a breaking change (although who would be relying on the current behaviour is a mystery to me).

Are you in a position to try out the current git main branch, and see if that works any better? As long as you're not actually referring to the GVB version constants (GVB::VERSION, et al), I think it'll work better than what's in the latest release, and if it does, I'll roll out a new version with this change in it, to give you some relief while I figure out the implications of the "larger" change.

[RoyWarps]

That solution looks good. It should solve the problem as GVB.version is no longer called during requiring which also resolves the warnings about redefining constants.
Given the constraint that they need to be accessible as constants this is a creative solution. I would say it is more important to avoid executing code while requiring than it is to technically have constants be immutable. At least in my experience execution during requiring is more problematic.

Looking forward to the new release.

[RoyWarps]

Are you in a position to try out the current git main branch, and see if that works any better? As long as you're not actually referring to the GVB version constants (GVB::VERSION, et al), I think it'll work better than what's in the latest release, and if it does, I'll roll out a new version with this change in it, to give you some relief while I figure out the implications of the "larger" change.

Unfortunately no. As the test framework pulls gems I cannot simply provide my own.
I am seeing about doing a test locally where I could indeed implement the changes directly into the gem sources.
Of course none if it is setup to make changes in underlying library's so it will involve some trickery.

[RoyWarps]

Ok quite a few tricks later I managed to reproduce the issue locally and then hacked your new version.rb into the local GVB gem source.
It works as expected it no longer calls GVB.version and thus doesn't crash upon hitting the synctag. It instead reports the version from the gemspec.

[mpalmer]

I've just pushed a commit that marks this issue as resolved, as it fixes the underlying problem of GVB pulling version info from a git repo rather than the gemspec. I'm not making a proper release just yet, because I'd like to have confirmation that it works for at least one other person before I release. For ease of testing, I've setup autobuilding of pre-release gems, so you can install the latest pre-release git-version-bump from rubygems and try it out, rather than having to manually hack in code changes.