CI: automate version increment in setup.py

[bzz]

Right now, before the release one have to manually updated&commit a new version number for python library in setup.py → setup.py
It would be nice to get it from the git tag instead.

[dpordomingo]

I understood that the setup.py file was moved, so I updated the broken link
setup.py → setup.py.

[bzz]

same solution will apply to bblfsh/sonar-checks#1

[danishprakash]

@bzz I would like to take this up and for the same, I have a question. Correct me If I'm wrong here but would it be right to update the VERSION param using a subprocess call to git tag -l | tail -n 1 given that we've already created the most recent tag.

[carlosms]

What I'm wondering now is: if we update the python code after the tag is made, the tagged code will always contain an outdated version number. Maybe it would be easier to automate a check for Travis, to avoid releasing a version with a version that does not match the tag.

A related issue: we have a __version__ in python/lookout/__init__.py that is outdated. This is set by protogen_python.sh, and that was based on the code from style-analyzer:
https://github.com/src-d/style-analyzer/blob/master/lookout/__init__.py

Maybe we could follow how it's done in that project.

• Move __version__ to python/lookout/sdk/__init__.py (one level below)
• Bump this __version__ manually
• Use it in setup.py, like here: https://github.com/src-d/style-analyzer/blob/master/setup.py#L18

[bzz]

@carlosms makes sense. Most probably, if we are talking about a generic solution applicable to all Python projects, we want it to cover 2 cases:

• pip install -e, version read from setup.py and the approach linked above works
• CI build, version read from git tag, pasted to the place setup.py imports from, so .whl get's built with the tag

@danishprakash I belive for the second case, a helper script replacing the version can just rely on TravisCI conventions (as releases are always done by CI automation) and read $TRAVIS_TAG env var

[carlosms]

But if the version is set by Travis after the tag is set, what does __version__ contain if you pip install -e on a tag, e.g. v0.2.0? I see two options:

• A placeholder string, like "0.0.0"
• An outdated value, v0.1.0

None would match the values of an install form pypi. Are we ok with that?

[danishprakash]

Maybe it would be easier to automate a check for Travis, to avoid releasing a version with a version that does not match the tag.

@carlosms I'm not very well-versed with CI but wouldn't that be redundant? I'm sure we can work up a more effective solution.

CI build, version read from git tag, pasted to the place setup.py imports from, so .whl get's built with the tag

As already stated by @carlosms, this would have to have an outdated value in which case we are back to square one. We'll have to manually set the version while creating a tag and although we can programmatically set the version in setup.py file, that's a given.

I can think of this. What if we have a separate file named .version and have the version inside it. In this case, we'll have to manually update the version var only once and can use it programmatically while creating a tag as well as in the setup.py file.

• tag: git tag $(cat .version)
• setup.py: with open('.version', 'r') as f: VERSION = f.read()

I'm not sure if this is the right approach or not but this should work.

[carlosms]

@danishprakash thank you for your valuable input on this discussion.

We have been talking internally about this need for a better release process, and we will try to come up with a generic solution to apply on all src-d python projects. I don't know how long it will take, but it will end up published in our python guidelines.

This means that it would not make sense for you to work on this issue, since it would have to be replaced in the short-term. But thanks again for offering your help and joining the conversation.

[danishprakash]

@carlosms totally understand that. It was really informative reading all of the responses here though. I'll keep an eye on this as well as your python guidelines for the approach you guys take. Thanks.

[se7entyse7en]

My two cents. I used to use this. Given that the creation of the git tag is manual, we could replace that operation by using bumpversion that does both creates the git tag and updates the version in the __init__.py file.

As an example we can simply configure bumpversion with this .bumpversion.cfg:

[bumpversion]
commit = True
tag = True
current_version = <xxx>  // this is to be set only the first time, then it is handled automatically

[bumpversion:file:python/lookout/sdk/__init__.py]

and we want to release a new version (both git tag and python version) we just need to run bumpversion major|minor|patch and push, then travis will do the same as now.

Another good thing of bumpversion is that it's not python specific, but for example we could also configure it to change the version inside a build.sbt or whatever.