Equivalent to VersionInfo.version_tuple()?

[nicoddemus]

Hi,

I'm trying to update mock to use setuptools_scm to solve testing-cabal/mock#385. Here's the relevant code in mock/mock.py:

from pbr.version import VersionInfo

_v = VersionInfo('mock').semantic_version()
__version__ = _v.release_string()
version_info = _v.version_tuple()

Replacing __version__ is simple enough, but how about the version_info tuple? Is there something in setuptools_scm which provides the same functionality?

Here's what version_info looks like for mock-2.0.0:

>>> import mock
>>> mock.__version__
'2.0.0'
>>> mock.version_info
(2, 0, 0, 'final', 0)

[nicoddemus]

Just found a related issue: #36.

[RonnyPfannschmidt]

@nicoddemus please note that if its already using pbr and its runtime metadata services (and likely its tooling for many related things, there is no point to push it to setuptools_scm on its own, as it handles only a subset of all that pbr does

(bascially pbr is a bug ball of features that breaks things for me ^^)

[RonnyPfannschmidt]

but in any case, what you request is a run-time service a install requirement would provide
additionally the proper content of a version tuple is undefined

[nicoddemus]

please note that if its already using pbr and its runtime metadata services

You mean mock? It only seems to import pbr in this line to get the version:

from pbr.version import VersionInfo

_v = VersionInfo('mock').semantic_version()
__version__ = _v.release_string()
version_info = _v.version_tuple()

There's no other import for pbr anywhere on the code.

[nicoddemus]

Currently setuptools_scm generates a file like this:

# coding: utf-8
# file generated by setuptools_scm
# don't change, don't track in version control
version = '2.0.1.dev1+ngb7a77db.d20161129'

I would like to propose to generate in addition something like:

version_info = (2, 0, 1, 'dev1', 'ngb7a77db.d20161129')

It seems like it could be useful and backward compatible. What do you think?

[jaraco]

It feels a bit messy to me to have setuptools_scm be generating a version file, but even more hacky for the version file to be generating multiple representations of a given version. If multiple version formats are necessary, mock should provide or require the tools necessary to perform those translations.

Reading the parent ticket, I see that the issue is that the cx_freeze model of packaging is not properly including the package metadata. I'll address that issue in the parent ticket.

[nicoddemus]

Thanks for joining in the discussion @jaraco, continuing on the parent ticket.

[RonnyPfannschmidt]

@jaraco there is a small reason to do generate the file - utility libraries may want to avoid the cost incurred by initializing pkg_ressources, but i dont see any other good reasons

[nicoddemus]

@RonnyPfannschmidt that's one of the points I made in the parent ticket.