Version fix

[JaviCerveraIngram]

The packages uploaded to PyPI were not reporting version number correctly. Our setup.py script was getting the version number as VERSION = environ.get('TRAVIS_TAG'). While this worked fine when Travis was generating the package and uploading it to PyPI (since TRAVIS_TAG was set to the tagged version that was being built), it was reporting None when installing the package from PyPI in the user's system, so version of the installed package was being reported as 0.0.0.

The way it works it has changed slightly. Now, the VERSION variable gets its value from the contents of the VERSION file, that is always available. When Travis is building the package from a tagged release, TRAVIS_TAG will be set, and this will cause Travis to overwrite the contents of the VERSION file with the new version.

[codecov-io]

Codecov Report

Merging #25 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #25   +/-   ##
=======================================
  Coverage   94.09%   94.09%           
=======================================
  Files          28       28           
  Lines        1084     1084           
=======================================
  Hits         1020     1020           
  Misses         64       64

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30b7f64...64f78db. Read the comment docs.

[marcserrat]

really there is no better way? I believe shall exist a better mechanism, relaying on this constant file for build seams quite fragile and prune to error

[vgrebenschikov]

IMHO - bad idea to commit that into git
file should be generated on build (when there is right environment) and then appear in package
in the way that all relevant tools (like PyCharm) will see it

[JaviCerveraIngram]

I took this approach to maintain the ability for Travis to generate the version number of PyPI build automatically. I honestly don't know if there's a better way to do this. Anyway, the file with the correct version should be autogenerated by Travis, so whatever we put in the VERSION file will be overwritten.

If no version can be parsed, the deployment process now fails, so I added a dummy VERSION file to make sure that if we are using connect-sdk directly from the GitHub repo and not from PyPI, it works (the team here does that when I add something they need to my fork and it has not been integrated yet into the official repo).

I can remove the default VERSION file if you prefer, but let the installation of the package continue if it doesn't exist so we don't get the default dummy file, but we can still switch to the fork of the repository correctly.

[JaviCerveraIngram]

Commited code with the changes.

[vgrebenschikov]

IMHO - too complex, and not really fair

There should be no reference to TRAVIS_TAG in package on pypi (connect-sdk-15.0.tar.gz)
Probably, best solution to write down version into setup.py on build on travis
like:
in git - setup.py looks like:
...
setup(
...
version='0.0.0',
...

in
.travis.yaml

script:

• sed -i "s/version = '0.0.0'/version = '${TRAVIS_TAG}'/g" setup.py

Then, setup.py will be modified only while travis build and then package will have just right constant in setup.py
Also, you can also modify connect/init.py same way (put version = '0.0.0' in git here)

[vgrebenschikov]

as above solution you can check V2 in https://stackoverflow.com/questions/48943503/travis-pypi-package-version

also, probably, it worth to use pbr (V1 by link above)

[vgrebenschikov]

probably, better to use 15.dev0 to match python version conventions

[JaviCerveraIngram]

Uploaded commit removing TRAVIS_TAG from Python code and using sed. Do we need PBR then? This solves the problem already and does not imply adding an additional dependency.