Use "git describe" to append a local version label #262
Conversation
setup.py
Outdated
| @@ -24,7 +41,7 @@ | |||
|
|
|||
| setup( | |||
| name='superflore', | |||
| version='0.3.0', | |||
| version=get_version_from_git_describe(), | |||
There was a problem hiding this comment.
@tfoote does this disrupt anything for releases?
There was a problem hiding this comment.
The release step that previously created a commit to change the value of version is replaced by one that adds a tag. @allenh1 < Would this be too much of a disruption?
There was a problem hiding this comment.
I've dropped this controversial commit from the PR and added various other improvements instead. Please re-review.
There was a problem hiding this comment.
Since I intend to someday propose an alternative implementation that addresses Tully's objections, I now think it would make more sense to create a new PR for the bitbake generator changes and just have the setup.py commit be in this PR.
|
@tfoote please review this one -- you know quite a bit more than I do about this. |
|
@herb-kuta-lge FYI |
There was a problem hiding this comment.
This is a neat trick, however I have two conceptual problems with it.
First is that you should generally never use external resources in your setup.py It creates a depedency in the tool that you use to list your dependencies. In this case, if you don't have the python git module installed you cannot install the package.
Secondly this assumes that there's always a git repository behind the deployment. There are alternative deployment mechanisms that could be used such as a tarball or debian package, or pypi none of those would work.
Along those same lines if you have a local checkout, and you make a custom tagged version you could end up not knowing what "version" your running. And it's a real problem for browsing through the code a user cannot know what version of the code is deployed or installed on their system from an editor.
shr-project
force-pushed
the
jansa/version
branch
5 times, most recently
from
ac5479a
to
661e9e3
Compare
shr-project
changed the title
There was a problem hiding this comment.
I think this should be implemented by requiring that --dry-run be specified when running superflore-gen-oe-recipes.
And README.md needs to be updated.
shr-project
force-pushed
the
jansa/version
branch
from
661e9e3
to
6e9fc0c
Compare
|
@herb-kuta-lge requested to split this pull request into smaller ones with separate issue tickets and to leave this original one for setup.py change he plans to update with different implementation based on @tfoote's feedback. I've created: |
shr-project
changed the title
herb-kuta-lge
force-pushed
the
jansa/version
branch
from
6e9fc0c
to
2d343ef
Compare
herb-kuta-lge
changed the title
|
@tfoote < Please review the latest implementation. I believe it addresses all of your concerns. |
herb-kuta-lge
dismissed
their stale review
The commits my comments applied to were moved to other PR-s.
setup.py
Outdated
| @@ -2,6 +2,51 @@ | |||
|
|
|||
| import sys | |||
| from setuptools import find_packages, setup | |||
| import git | |||
There was a problem hiding this comment.
No; I'll remove it (and the next line).
"superflore-gen-oe-recipes" generates a setting containing the version of the program that was used to generate the recipes. So that it's possible to know whether a released version has been used, automatically append to the version a local version label based on the output from "git describe --tags --dirty --broken".
herb-kuta-lge
force-pushed
the
jansa/version
branch
from
2d343ef
to
da479cf
Compare
…rastructure#262) "superflore-gen-oe-recipes" generates a setting containing the version of the program that was used to generate the recipes. So that it's possible to know whether a released version has been used, automatically append to the version a local version label based on the output from "git describe --tags --dirty --broken". Co-authored-by: Herb Kuta <[email protected]>
and small fix for superflore-datetime.inc.