Versions according to the Debian Policy Manual

[timofurrer]

I'm currently using setuptools-scm with pybuild to build debian packages.
The problem I'm facing right now is that we sometimes have tildes (~) in the version number, which doesn't seem to be supported.

When enabling the debug logs I get:

tag 0.8.1~alpha3
version <LegacyVersion('0.8.1~alpha3')>
version None

Along with the following traceback:

Traceback (most recent call last):
  File "setup.py", line 51, in <module>
    entry_points={"console_scripts": ["sts = sts.__main__:main"]},
  File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 320, in __init__
    _Distribution.__init__(self, attrs)
  File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
    self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 387, in finalize_options
    ep.load()(self, ep.name, value)
  File "/usr/lib/python3/dist-packages/setuptools_scm/integration.py", line 19, in version_keyword
    dist.metadata.version = get_version(**value)
  File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 117, in get_version
    parsed_version = _do_parse(root, parse)
  File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 66, in _do_parse
    return meta(pretended)
  File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 86, in meta
    assert tag is not None, 'cant parse version %s' % tag
AssertionError: cant parse version None

What's the correct way to workaround this? Would it be possible to support versions according to the Debian Versioning Policies?

See: Debian Policy Manual for the versioning policies.

[RonnyPfannschmidt]

indeed - debian version numbers are not python version numbers at all,
as far as i can tell there is no well defined mapping and its tricky to get right

it would be possible to support debian style version numbers in some way,
but i am not going to invent it and i'm not going to merge it unless it comes with good and comprehensible tests

[RonnyPfannschmidt]

also note that putting in debian style versions into packages that use normal python versions is pretty much a breaking change to the package

[timofurrer]

as far as i can tell there is no well defined mapping and its tricky to get right

Agreed.

but i am not going to invent it

Where would I have to hook into setuptools-scm to write my own version parsing algorithm / mapping?
Could I implement it as a plugin / external hook to setuptools-scm?

also note that putting in debian style versions into packages that use normal python versions is pretty much a breaking change to the package

That's right. I mainly see a use case where the main target are debian systems - and the package isn't even additionally deployed as python package.

[RonnyPfannschmidt]

if you map the debian versions to valid python versions in your pretend versions,
then all you need to do is turn 1.4~alpha3 into 1.4+debian.alpha3 - then its a local python version and valid for python packages (which ensures that a debian packaged python package will not break well done python package version expectations)

i would advise strongly against teaching setuptools_scm debian versions

[RonnyPfannschmidt]

also note that if you deploy python packages as debian packages, those python packages may still use python tooling around package version numbers, having it be valid python versions means you dont have to fix them up to support debian numbers

[aspiers]

Regardless of how setuptools_scm handles version numbers, I strongly believe it should offer more helpful error messages than a stacktrace followed by AssertionError: cant parse version None. Please can this be fixed at least?

[aspiers]

I've submitted that as #261.

[RonnyPfannschmidt]

indeed, i will take a look at the next larger timeframe

[RonnyPfannschmidt]

@timofurrer now that the initial details are solved i believe its a good point in time to look into ensuring debian style versions are mapped to correct python versions

[timofurrer]

You've mentioned in a previous comment:

i would advise strongly against teaching setuptools_scm debian versions

Thus, where do you want:

debian style versions are mapped to correct python versions

to be? In setuptools_scm ?

[RonnyPfannschmidt]

my current idea this should have 2 parts

a) the part in setuptools_scm that enables distros to push their own tagging style that missmatches the language
b) a separate distro specific tool that takes the distro versions and turns them into valid python versions

then the distro will push such a lib into the machinery of setuptools_scm via environmental configuration and the result will have 2-fold advantages as the distro versions are honoured exactly and the python meta-data matches and is valid for python

in the end the tag would be a debian version and the generated metadata for python would be a python version

[RonnyPfannschmidt]

its unlikely i can put time into the details within the next 1-2 years for this one

[matthijskooijman]

Not sure if this was clear already, but the ~ is a bit special in Debian versioning, since it sorts before everything, including the empty string. So 1.4.0~rc1 sorts before 1.4.0. This is something that a lot of versioning schemes do dot support (which leads to using versions like 1.3.99~rc1 instead).

I'm not sure if Python versioning allows something similar, but if it does not, this means that these ~ versions cannot be supported without changing their meaning. It might still be useful to allow ~ in version numbers by replacing it with something else, but please do not do so by default, since this breaks proper version sorting. Having an explicit opt-in could be useful, when someone knows what they're doing and needs this for e.g. local testing only or something.

[RonnyPfannschmidt]

Again, the tilde is invalid for python versions and has to be mapped to a local version tag as per the python standards for version numbers

[matthijskooijman]

I realize that: I'm just emphasizing that if you map it, you will likely end up signficantly changing the meaning of the version number, so it is probably not good to do this without explicit instructions.

[RonnyPfannschmidt]

i never was suggesting that i or setuptools_scm maps it, it should be entirely the job of something distro specific that can actually know what its doing

[matthijskooijman]

Ah, seems I had not read this thread properly (especially #246 (comment)). That indeed sounds like an acceptable plan, just let some distro-specific tool sort this out (which can then error out on impossible-to-map versions if needed). Apologies for the noise...

[RonnyPfannschmidt]

I'm more than happy to provide feedback and integration with setuptools_scm, but I'm not going to work on distro specific tools myself

[timofurrer]

I totally agree that this might be the topic for another separate tool and let setuptools_scm do what it currently does.

Feel free to close this issue for now

I think once there are efforts made towards an integration into setuptools_scm - a new issue will come up any ways :)

[RonnyPfannschmidt]

Closing as not planned, distro input never came