#465 Use setuptools-scm to get version with a git tag by pombredanne · Pull Request #510 · aboutcode-org/scancode-toolkit

pombredanne · 2017-02-22T08:24:11Z

Signed-off-by: Philippe Ombredanne pombredanne@nexb.com

pombredanne · 2017-02-22T08:24:29Z

sschuberth · 2017-02-22T08:52:42Z

Cool, just today I was missing that feature again! But even after reading about the scheme I'm having difficulties to understand how exactly it works.

For my local repo (with some custom merges) I get 2.0.0rc3.dev101+ng2ec2cb59. But where does the 2.0.0rc3 part come from, as there is no such tag, and the latest tag is v2.0.0.rc2? From setup.py?

Also, even after creating local (lightweight and annotated) tags, I still see the "distance" part of "101", and the tag name not being picked up.

Finally, I believe in our case the "dev" prefix is misleading as one could misunderstand it to refer to the "develop" branch, which it does not. I'd prefer to make the scheme match exactly the one of git describe, i.e. "{tag}-{distance}-{revision hash}".

Note that there seems to be a bug in the documentation of setuptools_scm as {revision hash} is not exactly the Git revision hash, but the Git revision hash prefixed by "g" as git describe would use it. That's why with the default scheme you get the awkward "ng" (which sounds like "next generation") prefix for the hash.

pombredanne · 2017-02-24T09:34:08Z

2.0.0rc3 comes either from the version in setup.py to which things are added as I did not remove that. Or it is setuptools_scm that seem to always bump the minor or patch segment from the latest tag e.g. 2.0.0rc2 if the workspace is "dirty" e.g not on the tag.

sschuberth · 2017-02-24T10:02:22Z

The setuptools_scm docs say the default scheme to use {next_version} if there is a distance. I don't like this "auto-bumping" because I prefer to refer to the app's revision using existing tags, not some that may or may not exist in the future. For example, how's the bumping logic supposed to now if after 2.0.1 comes 2.0.2, or 2.1.0 as you've a big number of features?

pombredanne · 2017-02-24T10:58:25Z

@sschuberth would you know what to do to get this behavior then?

sschuberth · 2017-02-24T11:27:18Z

After reading through this post it seems the solution is to not set use_scm_version to a bool, but to dict overriding version_scheme with one of the available implementations like

use_scm_version={
    'version_scheme': 'post-release'
},

But that still does not seem to work fully. While I now see strings like

Requirement already satisfied (use --upgrade to upgrade): SPARQLWrapper in ./lib/python2.7/site-packages (from rdflib->spdx-tools>=0.4.1->scancode-toolkit==2.0.0rc2.post102+ngd137d38e.d20170224

when running ./configure, and the contained 2.0.0rc2.post102+ngd137d38e.d20170224 looks better WRT to not using "rc3", ./scancode --version still shows

ScanCode version 2.0.0rc3.dev102+ngd137d38e.d20170224

Not sure why there's rc3 (and also dev instead of post) still in there.

sschuberth · 2017-02-24T11:38:48Z

FYI, I've also added a comment about the misleading "g" here.

pombredanne · 2017-02-24T13:22:15Z

@sschuberth Thanks. wrt to the scancode --version, it comes from elsewhere. I will sync that up once we agreed on something decent.

pombredanne · 2017-02-24T16:19:38Z

@sschuberth setuptools_scm is too sophisticated. I just added a few extra lines in setup.py to the same (controllable) effect.

sschuberth · 2017-02-24T16:49:28Z

+    # this may fail with exceptions
+    cmd = 'git', 'describe', '--tags', '--long', '--dirty',
+    version = check_output(cmd, stderr=STDOUT).strip()
+    dirty = version.endswith('-dirty')


Funny, that's basically exactly the same that I've implemented meanwhile in setuptools_scm :-)

ah! sorry... I had not tracked you were submitting a PR there. If we can switch back to setuptools_scm later this would be great. Though it does not handle any fallback to a default version...

No, I was no meaning to say you should continue using setuptools_scm. It will take me more time (and be convincing) to shape it into what I'd expect ;-)

sschuberth · 2017-02-24T16:51:08Z

+    __version__ = get_distribution('scancode-toolkit').version
+except DistributionNotFound:
+    # package is not installed ??
+    __version__ = '2.0.0rc3'


Is there a way to use the version from setup.py so the fallback is only hard-coded once?

This is what should happen, but I am playing it safe. The versions are updated at once in all places with bumpversion in anycase

sschuberth · 2017-02-24T17:06:20Z

So I just tried the latest state. With this, the version may look like

ScanCode version 2.0.0rc2.dev105+31d696e5

or

ScanCode version 2.0.0rc2.dev105+31d696e5.dirty.20170224170011

Personally, I don't like the . before dev. I'd prefer - to visually separate more from . in the version number. Also, I don't like dev as it might again be confused with the develop branch. Likewise for the +, let's be consistent with the separators and only use -. But I do like that the date is only added in case of dirty.

So, bottom line, how about this instead:

ScanCode version 2.0.0rc2-post105-31d696e5

and

ScanCode version 2.0.0rc2-post105-31d696e5-dirty-20170224170011

?

pombredanne · 2017-02-24T17:11:46Z

Please update as you please ... The only constraint would be to ensure that this ends up being compliant with https://www.python.org/dev/peps/pep-0440/ and that its sorts well.

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

* do not use setuptools_scm * collect git describe and fallback to default version * get version as installed in scancode or fallback to default too. Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne · 2017-02-26T17:54:05Z

I made a few tests with your proposed scheme:
The version specified ('2.0.0.rc2-post111-0df8a27-dirty-20170226174708') 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.

and

The version specified ('2.0.0.rc2.post111-0df8a27-dirty-20170226174805') 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.

and

Normalizing '2.0.0.rc2.post111+0df8a27-dirty-20170226174839' to '2.0.0rc2.post111+0df8a27.dirty.20170226174839'

So net-net is that dashes are in all cases replaced by dots or creating a non-compliant version wrt. PEP440.

'2.0.0rc2.post111+0df8a27.dirty.20170226175122' is the scheme that works and sorts. Let's go with this for now.

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne force-pushed the 465-use-vcs-for-version branch from fb47886 to 7242b65 Compare February 22, 2017 08:25

pombredanne changed the title ~~#465 Use etuptools-scm to get version with a git tag~~ #465 Use setuptools-scm to get version with a git tag Feb 22, 2017

sschuberth reviewed Feb 24, 2017

View reviewed changes

pombredanne force-pushed the 465-use-vcs-for-version branch 2 times, most recently from d296b7b to 9dfe1dd Compare February 25, 2017 22:26

pombredanne added 2 commits February 26, 2017 00:25

#465 Use setuptools-scm to get version with a git tag

648ff24

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

#465 Ignore egg dir from setuptools_scm

410d3ab

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne force-pushed the 465-use-vcs-for-version branch from 9dfe1dd to 830cc92 Compare February 25, 2017 23:25

#465 Use minimal version from git or from default

9e8a9e9

* do not use setuptools_scm * collect git describe and fallback to default version * get version as installed in scancode or fallback to default too. Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne force-pushed the 465-use-vcs-for-version branch from 830cc92 to 9e8a9e9 Compare February 26, 2017 08:22

#465 Remove duplicated setuptools alias entry in setup.cfg

0df8a27

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne force-pushed the 465-use-vcs-for-version branch from bbcaaa7 to 0df8a27 Compare February 26, 2017 14:59

#465 Improve Git version scheme

755fe78

Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne merged commit 6469c42 into develop Feb 26, 2017

pombredanne deleted the 465-use-vcs-for-version branch February 26, 2017 17:55

Uh oh!

Uh oh!

Conversation

pombredanne commented Feb 22, 2017

Uh oh!

pombredanne commented Feb 22, 2017

Uh oh!

sschuberth commented Feb 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pombredanne commented Feb 24, 2017

Uh oh!

sschuberth commented Feb 24, 2017

Uh oh!

pombredanne commented Feb 24, 2017

Uh oh!

sschuberth commented Feb 24, 2017

Uh oh!

sschuberth commented Feb 24, 2017

Uh oh!

pombredanne commented Feb 24, 2017

Uh oh!

pombredanne commented Feb 24, 2017

Uh oh!

sschuberth Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

pombredanne Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

sschuberth Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

sschuberth Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

pombredanne Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

sschuberth Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

sschuberth commented Feb 24, 2017

Uh oh!

pombredanne commented Feb 24, 2017

Uh oh!

pombredanne commented Feb 26, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sschuberth commented Feb 22, 2017 •

edited

Loading