Change design to "operation mode"

[yajo]

After seeing the way dunamai is done, and problems like #32, I think there's a conceptual problem: it tries to have an input regexp to rule them all. IMHO if I'm parsing a PEP440 project, dunamai should instead:

1. Extract latest tags.
2. Pass them through packaging.version.Version
3. On failure, skip the tag.
4. When found the one closest to current commit, continue.
5. Append .dev{commit_number}+{commit_hash} as needed.

Which of course doesn't make any sense if I'm on a semver project.

This would make its behavior more predictable, and it would save dunamai from maintaining the correct regexp (it won't work as a drop-in for dunamai, BTW).

So, instead of an input regexp and an output format, dunamai should just have a mode of operation, which affects both input and output.

[mtkennerly]

This is something that I considered during the initial design, but I think it would create too tight of a coupling between version-like tags and the output version. For example, right now, you could have a tag like v-a1-1.2.3 and then define Dunamai's --pattern so that it's converted to the version 1.2.3a1. Your proposal would require that tags already be in a format recognized by PEP-440, whereas Dunamai's design allows version-like tags to be in any arbitrary format, which I think is an important feature to continue supporting.

[yajo]

But you could still preserve that with one "custom" operation mode, where the regexp is required.

Also you could support different operation modes for in and out. I.e. you could use custom for in and PEP 440 for out. However that'd have its own challenges, as different version systems have different parts. For example, you cannot convert a PEP 440 with epoch to a semver.

[mtkennerly]

You could describe the current functionality as having a single in-mode (--pattern) and four out-modes (3 from --style and 1 from --format). Issues like #32 are infrequent enough that I don't think it's worth supporting another in-mode, unless there's a use case that can't be covered by the current design.

[yajo]

Yes, PEP 440 epoch is not supported AFAIK. Although probably it could be supported by just adjusting the regexp a little bit more and adding the new epoch concept to it.