Multiple tags result in "unknown" even if correct tag exists

[andrewmichaelsmith]

We want to use versioneer to version multiple python packages in a single git repo.

I have 2 setup.cfgs with:

tag_prefix=ExampleA-

and

tag_prefix=ExampleB-

In my case I have 2 directories with versioneer installed. And I tag a single commit twice:

git tag ExampleA-1.2.3
git tag ExampleB-2.3.4

I was assuming that doing an sdist upload would result in the ExampleA being versioned as 1.2.3 but it goes up as "unknown".

Turning on verbose I get

tag 'ExampleB-2.3.4' doesn't start with prefix 'ExampleA-'

Looking at the code it looks like this is from the use of "git describe" which takes the most recent commit. So I suppose this would need to be changed to look at all the tags, not just the most recent one.

Do you envisage supporting this use case? Or am I missing something?

[warner]

Hm, that's not a use case I'd considered before, but I think we ought to support it. As long as each (setup.py/setup.cfg/versioneer.py) triple are next to each other, it should be possible to support multiple projects in a single repo.

The code isn't very good about tolerating multiple tags yet, but I'd like to fix that.

The first rule will be to ignore any tags which don't start with the configured tag_prefix. The second rule (which is trickier) is to somehow accept the "highest" matching tag.. the use case I'm thinking of is where a release-candidate gets promoted to Final without intervening changes, so the last commit has two tags like "v1.0rc3" and "v1.0", and we want it to assign a version of "1.0". It might be easiest to just pick the shortest tag.

The other pressure is that I'd like a good error message in case people misconfigure their tag_prefix, since I've done that a zillion times and then have to wonder why I'm getting "unknown" all the time. I guess it's probably sufficient to print that "tag doesn't start with prefix" message when verbose=True, and then maybe additionally turning on verbose-mode whenever you run setup.py version, and document that as the command to run to check that everything is working correctly.

I'd originally made it bail as soon as it saw a mis-prefixed tag to make the error case easy to spot, but maybe verbose=True is sufficient.

[DanLipsitt]

I'm having a related issue because I have tags with different prefixes than the tag_prefix that are often newer. For example, I have a release v1.1 and then some changes to add debian packaging and then a tag like debian/1.1.

The "highest tag" problem looks easy if you use distutils.version.StrictVersion to sort (or possibly LooseVersion). More info.

[DanLipsitt]

OK, I've got a proposed solution in #78. It uses git describe's --match flag to only select tags that match tag_prefix. It looks like git chooses the closest commit rather than sorting tags, so this might not provide the expected tag in all circumstances. But it's probably better than just grabbing the most recent even if it doesn't match the prefix. Let me know what you think.

[warner]

Landed, thanks. My brief tests suggest that, when there are multiple tags on a single commit, git-describe returns the highest-sorting one (so zzz-1.0 beats aaa-1.0). When there is no tag on the current commit, a wrong-prefix tag on the previous commit, and a right-prefix tag on the grandparent commit, git-describe with --match correctly ignores the wrong-prefix tag and reports e.g. v1.0-2-gHASH instead of zzz1.0-1-gHASH. And I checked the Git release notes, --match has been around since git-1.5.5, so it's probably safe to use.

So I think this might fix the problem, although it might also hide the error situation that I was worried about (a typo in tag_prefix). Maybe we could add an extra call to find all tags and refs that point to the current version (matching and non-matching), and include them in a verbose string somewhere. We've got a request to include the current branch name too, for which we need to grab all the refs anyways. Something like git log --decorate --max-count=1 with some --pretty options to only list the refs.

[andrewmichaelsmith]

Thanks @warner and @DanLipsitt for taking the time to look at this.

Have tested with the case described above and confirmed this as fixed in current master.

There's another issue I have with tags, but as this is fixed I will raise that separately. Thanks!