@yarikoptic Care to review? Regardless of how #255 turns out, this seems like it should be correct.

Regardless of how #255 turns out, this seems like it should be correct.

well, tag_match is introduced, then we would need then probably default it similarly to that git_describe_options to have the [[:digit:]] so overridden tag_match could replace it whenever desired.

@yarikoptic Care to review?

I have a general reservation against this approach for probably no more (if any) of 1% of use cases where someone does have a version which doesn't start with a digit but some alpha/letter for some obnoxious reason (e.g. lib0.1). I do not think that versioneer ATM cares for the version to be semver or alike. If we default to such restriction without giving a way around it, that 1% of people wouldn't be able to upgrade to newer versioneer... so boils down if we want to impose on those folks? ;-)

I have a general reservation against this approach for probably no more (if any) of 1% of use cases where someone does have a version which doesn't start with a digit but some alpha/letter for some obnoxious reason (e.g. lib0.1). I do not think that versioneer ATM cares for the version to be semver or alike. If we default to such restriction without giving a way around it, that 1% of people wouldn't be able to upgrade to newer versioneer... so boils down if we want to impose on those folks? ;-)

Huh.

nibabel$ python setup.py version
running version
keywords are unexpanded, not using
got version from VCS {'version': '3.2.1+103.ge51bcb43', 'full-revisionid': 'e51bcb43d9c6f5ad329ffb230afda0c26b9e8617', 'dirty': False, 'error': None, 'date': '2021-05-21T07:55:20-0400'}
Version: 3.2.1+103.ge51bcb43
 full-revisionid: e51bcb43d9c6f5ad329ffb230afda0c26b9e8617
 dirty: False
 date: 2021-05-21T07:55:20-0400

nibabel$ git tag -a -m "lib0.1" lib0.1

nibabel$ python setup.py version
/home/chris/miniconda3/lib/python3.8/site-packages/setuptools/dist.py:466: UserWarning: The version specified ('lib0.1') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.
  warnings.warn(
running version
keywords are unexpanded, not using
got version from VCS {'version': 'lib0.1', 'full-revisionid': 'e51bcb43d9c6f5ad329ffb230afda0c26b9e8617', 'dirty': False, 'error': None, 'date': '2021-05-21T07:55:20-0400'}
Version: lib0.1
 full-revisionid: e51bcb43d9c6f5ad329ffb230afda0c26b9e8617
 dirty: False
 date: 2021-05-21T07:55:20-0400

I guess technically it supports non-PEP440 tags. Though if I try to pip install, it complains loudly and falls back to a deprecated method.

[...]
  WARNING: Built wheel for nibabel is invalid: Metadata 1.2 mandates PEP 440 version, but 'lib0.1' is not
Failed to build nibabel
Installing collected packages: nibabel
  Attempting uninstall: nibabel
    Found existing installation: nibabel lib0.1
    Uninstalling nibabel-lib0.1:
      Successfully uninstalled nibabel-lib0.1
    Running setup.py install for nibabel ... done
  DEPRECATION: nibabel was installed using the legacy 'setup.py install' method, because a wheel could not be built for it. A possible replacement is to fix the wheel build issue reported above. You can find discussion regarding this at https://github.com/pypa/pip/issues/8368.
Successfully installed nibabel-lib0.1

It feels to me like not something we should try to support.

I guess technically it supports non-PEP440 tags. Though if I try to pip install, it complains loudly and falls back to a deprecated method.

yes it does. Do we know if versioneer is only used for Python projects? anyways -- I do agree that it feels that we shouldn't even bother supporting versions which do not start with version a digit, but

1. versioneer does support them ATM so these change has potential to break existing workflows. Somewhat good that versioneer is not used as a module and usually people just carry a copy, right? Only "somewhat" is that we wouldn't discover if any workflow got broken until awhile ;)
2. we don't know if/how many people use it for some odd (or not so odd, just rare) scenarios where they might like some adhoc version to be populated (possibly to be tuned up later "in code"). edit: think about some composite lib-X.Y-client-A.B split in code into two for different components... who would do that? I don't know yet ;)

It is specifically a patch into distutils/setuptools' setup.py implementation, so the 99+% use case is going to be Python packages. Maybe somebody's doing wacky things with setup.py to create non-Python packages, but a simple solution to the 99+% case seems better than a complex solution to a niche use case that we have no evidence for.

As you say, people do need to manually upgrade to a new version of versioneer, and we can get a report when it happens. Your approach isn't going to be harder to implement at that time, and that time may never come.

Supporting non-python projects is not in scope, so non-PEP-440 tags are not in scope.