Confusing behavior (bug?) v0.0.0 fallback code does not work if there are *any* tags in the repo

[jfly]

In a brand new repo, dunamai falls back to assuming we're on version 0.0.0.

Setup

$ cd $(mktemp -d)
$ git init
$ echo hiya > README.md && git add README.md && git commit README.md -m "first commit"
$ pip install dunamai
...
Successfully installed dunamai-1.20.0

Fallback demo:

$ dunamai from git --bump --dirty
0.0.1.dev1+695edd0.dirty

Now add any tag, and dunamai refuses to generate a version:

$ git tag just-some-tag
$ dunamai from git --bump --dirty
The pattern did not match any tags

Pattern:
(?x)                                                        (?# ignore whitespace)
    ^v((?P<epoch>\d+)!)?(?P<base>\d+(\.\d+)*)                   (?# v1.2.3 or v1!2000.1.2)
    ([-._]?((?P<stage>[a-zA-Z]+)[-._]?(?P<revision>\d+)?))?     (?# b0)
    (\+(?P<tagged_metadata>.+))?$                               (?# +linux)

Tags:
['just-some-tag']

This is a pretty great error message, thanks! Love that the tags are printed. ❤️

However, this behavior is arguably a bit confusing: it seems a bit restrictive to assume that all tags in a repo are meant to be release tags for this Python package. This is particularly false in a monorepo scenario (such as mine) where you may be adding a new package to an existing repository with a bunch of tags that are totally unrelated to the package you're adding.

Unlike mtkennerly/poetry-dynamic-versioning#178 (which mostly just a cosmetic nice to have), I'd quite like to see this use case supported, as it introduces quite a bit of friction when developers add a new package to our monorepo: a new package that uses poetry-dynamic-versioning won't build until it has been released, and we don't want developers to have to do a release of a brand new (possibly experimental) package just to be able to build it and test it out locally.

I'd be happy to send in a PR implementing something here if we can agree upon what to do. A few ideas:

1. Controversial (arguably breaking) change, but simplest: Remove the "The pattern did not match any tags" check in dunamai entirely. If no tags match the pattern, use the existing fallback to v0.0.0 code.
2. Add a knob to dunamai and poetry-dynamic-versioning: add a new setting to dunamai to disable the "The pattern did not match any tags" check and expose it in [poetry-dynamic-versioning].
   • Depending on where we land on Feature request: optional tag prefix for monorepo support poetry-dynamic-versioning#178, you could imagine that we build these features to play nicely together: if a pattern-prefix (or whatever we call it) is set, then we could automatically disable dunamai's "The pattern did not match any tags" check.

[mtkennerly]

Thanks for the detailed ticket!

I think option 1 makes sense. "There are no tags" and "there are no tags that match the pattern" aren't all that different, and we can extend --strict to preserve the current error.

Regarding potential breakage:

• Since this only applies before you have a version tag, the scope is pretty small.
• If you handle the current error, then you'd probably set a fallback version as well.
• If you prefer a different fallback version than 0.0.0, then you already have to check if Dunamai gives you 0.0.0 so you can use something else instead, since we use 0.0.0 in several other cases.
• If you're worried about cases where CI doesn't have the full history and only fetches a subset of tags (possibly not including any version-like tags), then you should be using --strict.