Option to specify version tag prefix

[bryceschober]

In order to bring this tool to bear in repos that might have been tagged in a different way, it'd be nice to be able to specify a prefix or even a list of prefixes for tags to include in the processing.

[bryceschober]

@mbdevpl: Are you watching this repo? Or should I go somewhere else to collaborate?

[mbdevpl]

@bryceschober Hi! I'm watching it, but somehow the previous notification got lost among other updates... Thanks for the interest in this project :) Yes, customization of the version tag prefix seems like a useful addition. Do you have any specific project in mind at the moment?

[bryceschober]

@mbdevpl Not a public one, but an example would be a mono-repo that was the point of development for a few modestly-independent libraries in which the maintainer might separate semantic version streams for each library.

[mbdevpl]

@bryceschober I think this feature needs a use case - I don't think testing it on exclusively synthetic examples is a good idea. So by all means, if you have a specific open source use case in mind, please let me know here.

Apart from the testing, do you have any idea how this feature's API might look?

[bryceschober]

I agree about a concrete use case.

A usage should be optional, of course:

version_query.set_prefix_to_ignore("subproject-foo-")
version_string = version_query.query_version_str() # given tag "subproject-foo-v1.3.9" yields "1.3.9"

And I could imagine that the implementation might be as simple as removing the prefix at the beginning of preprocess_git_version_tag, but I'm probably being naive.

[bryceschober]

Oh, and I found a public open-source example: https://github.com/stellar/go

[bryceschober]

@mbdevpl So I've experimented with a painfully awkward attempt at implementing this, and here's my hacky-crap version: master...DynonAvionics:master

Some notes:

1. It breaks all of the tests, because I was lazy
2. It sure isn't pretty
3. It works in my private test cases and on a clone of https://github.com/stellar/go:

   $python3 -m version_query -sbifrost- ~/git/go 2> version.log
   0.0.2
   $ python3 -m version_query -sfederation- ~/git/go 2> version.log
   0.2.1
   $ python3 -m version_query -shorizon- ~/git/go 2> version.log
   0.14.2

4. Since the module isn't object-oriented at all, I didn't see an easy way to accomplish my goal, so I just beat my head down the path of adding a required parameter all the way down the stack, with the exception of a few top-level functions. It's quite possible that there is a much better way to accomplish this in your mind. Maybe a global would be better than the effect my changes had.
5. I note that my implementation (as previously suggested) flattens the "namespace of versions, so that any intended "top-level" version tags like "v1.0.0" would get mashed next to "libfoo-v1.0.0". In my use case, and in the public example, that wouldn't be a problem.