Extract package version from git

[DifferentialOrange]

setup: do not include test files

Include only tarantool package and subpackage code on install. Before this patch, test suites were installed as well.

Part of #238

setup: use git version instead of hardcoded one

setuptool_scm [1] package is a recommended way to set package version with git [2]. Version 6.4.2 was chosen due to Python 3.6 support, latest version 7.0.5 supports only Python 3.7+.

Package version is displayed in documentation, so after this patch documentation for master branch won't be confused with the last tagged one.

Version file is created when a user installs the package with pip install or on sources packing with python setup.py bdist_wheel command (readthedocs building pipelines install the package). If one would simply clone the repo, package __version__ would be a 'dev' placeholder.

1. https://pypi.org/project/setuptools-scm/
2. https://packaging.python.org/en/latest/guides/single-sourcing-package-version/

Part of #238

setup: update install command

Using pip install . instead of python setup.py install is a modern way to install local package [1]. With outdated way, setuptools+pip fail to resolve dependencies for different versions (in our case, Python 3.6 and Python 3.7 runs will fail with "No module named 'numpy'" on pandas install while trying to install unsupported latest version). Excessive build_py stage is also skipped.

1. https://setuptools.pypa.io/en/latest/userguide/quickstart.html

Part of #238

[DifferentialOrange]

It seems to me that the patch complicates a user experience.

1. A user can't just use the source code without SCM.

2. It is not really necessary to install the package.

I would prefer a generated _version.py file for tags at least or we can just not to use __version__ constant at all in the our code.

I have made new revision of the PR.

File tarantool/version.py is imported in __init__, if presents, and the version is extracted. Version file is created on build_py command. If there is no file, __version__ is 'dev'.

So how it works:

• if a user installs a module as a dependency or with explicit pip install tarantool (from branch or master), version.py is created with tarantool/tarantool-python module Git version value
• if a user clones a repo and works with it, version.py is not created ('dev')
• if a user clones a repo, installs the package with make install which is pip install --editable ., and works with it, version.py is not created ('dev')
• if a user clones a repo, installs the package with old-styled python setup.py install, and works with it, version.py is created with tarantool/tarantool-python module Git version value
• if a user makes local packaging like in our current wiki guides, version.py is created with tarantool/tarantool-python module Git version value

The first three seems nice: there is no inconveniences. The latter two could be a minor drawback: changes in version.py could make local test run fail until one clean up version.py file (failing test tells that to a user).

There are two possible ways: either we assert that every source code-based test run should be with 'dev' version or we allow to version to be anything possible if tarantool is installed as a package and source code is presents. I think that the first one is preferable: we can miss possible issues if we implement the second one.

[DifferentialOrange]

But I'm not sure that dev is a valid/idiomatic version value. Maybe it would be better to do something like 0.0.0-dev? Do you have examples of some kind of similar solution?

To be honest, it was simply the first thing that came to my mind. 0.0.0-dev is definitely better. Thank you, updated