setuptools incorrectly picks tag between multiple lightweight tags (github release)

[ssbarnea]

Assuming the current comment has multiple tags, setuptools only picks the first one, when it would be better to pick that last one instead.

Multiple tags on same commit are not uncommon and they can naturally occur on:

• need to retrigger release pipeline after a networking issue (usually incrementing tag name)
• transforming a pre-release into a release, like 1.0rc2 -> 1.0 (apparently this case works fine, probably because available tags are listed alphabetically before picking one?)

$ git tag --points-at HEAD
0.1a2
0.1a3
0.1a4

In this case setuptools will always pick 0.1a2 regardless how many additional incremental tags are added. This is quite problematic if you have a release pipeline that does not allow overriding versions.

I know that pypi does have an option to ignore existing packages on upload but using it would be a very risky practice.

At this moment, the only workaround I seen for this issue is to add extra commits and avoid having multiple tags on the same commit.

In context with use of GitHub release process, it can easily happen for a specific commit to endup with multiple tags. A simple edit of a release tag name on the web interface would create a new tag, for the same commit, but the triggered pipelines will end-up trying to release the old tag instead of the current one.

After playing a little bit more with git tag listing I was able to identify that order confusion happens only with lightweight tags.

The really bad part is that github seems to generate only lightweight tags and that we cannot prevent users from creating light tags, so the chance of ending up with multiple light tags is real.