Move from setup.py to pyproject.toml + tox

[kiudee]

Still to do

• [x] Migrate setup.py to pyproject.toml
• [x] Setup tox.ini
• [x] Update .travis.yml to use poetry and add missing dependencies.
• [x] Remove unneeded files

Motivation and Context

Currently we have several places where dependencies are specified (i.e. setup.py, requirements-dev.txt, create_testenv.sh, .travis.yml). This is hard to maintain and often causes failed travis-ci builds. Migrating to a pyproject.toml managed by poetry allows us to unify all our dependencies.

How Has This Been Tested?

Running all tests in an environment set up by poetry.

Does this close/impact existing issues?

Closes #110

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [ ] I have added tests to cover my changes.

[codecov[bot]]

Codecov Report

Merging #156 into master will decrease coverage by 0.46%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #156      +/-   ##
==========================================
- Coverage   57.04%   56.57%   -0.47%     
==========================================
  Files         113      113              
  Lines        6560     6543      -17     
==========================================
- Hits         3742     3702      -40     
- Misses       2818     2841      +23     

Impacted Files	Coverage Δ
csrank/objectranking/baseline.py	61.53% <0.00%> (-7.70%)	:arrow_down:
csrank/discretechoice/baseline.py	61.53% <0.00%> (-7.70%)	:arrow_down:
...ng/letor_listwise_object_ranking_dataset_reader.py	58.82% <0.00%> (-5.89%)	:arrow_down:
...anking/tag_genome_object_ranking_dataset_reader.py	33.33% <0.00%> (-5.80%)	:arrow_down:
...cefunctions/letor_ranking_choice_dataset_reader.py	55.55% <0.00%> (-5.56%)	:arrow_down:
...e/letor_listwise_discrete_choice_dataset_reader.py	57.14% <0.00%> (-4.77%)	:arrow_down:
...ce/letor_ranking_discrete_choice_dataset_reader.py	50.00% <0.00%> (-4.17%)	:arrow_down:
csrank/choicefunction/baseline.py	35.71% <0.00%> (-3.58%)	:arrow_down:
...r/choicefunctions/expedia_choice_dataset_reader.py	36.66% <0.00%> (-3.34%)	:arrow_down:
...techoice/expedia_discrete_choice_dataset_reader.py	33.33% <0.00%> (-2.78%)	:arrow_down:
... and 58 more

[kiudee]

Ok, I am back from holiday and pushed the current version of my parallel tox configuration. I crawled through many pages of documentation and looked at different repositories but I did not find a good solution on how to parallelize the builds on travis-ci than the one on the branch. I welcome any input on which mechanism I could use to make that more elegant.

[timokau]

I haven't found a better method during my fairly brief research just now. Given that we might want to experiment with GH actions as an alternative anyway and since tox solves some issues right now, I would tend to just declare CI parallelization improvements as "out of scope" for this PR for now.

[timokau]

Slightly off topic, but here is some motivation for some future GH actions experiments.

[kiudee]

Slightly off topic, but here is some motivaiton for some future GH actions experiments.

Good link. Another good resource is: https://cjolowicz.github.io/posts/hypermodern-python-06-ci-cd/

[kiudee]

Ok, it seems that the parallel builds work so far. The only thing failing is the docs build due to a pandoc error. I will investigate.

[kiudee]

What do you mean with "for pypi"? Could you add a short comment inline that explains the reason for pinning, so that we know when we can lift the pin?

Poetry uses the python requirement to generate classifiers (see here) like:

Programming Language :: Python :: 3
Programming Language :: Python :: 3.7
Programming Language :: Python :: 3.8

edit: I checked, if poetry adaptively sets the python version based on the dependencies by producing a build (poetry build). It does not. On second thought, I am not sure whether we should even pin it, since our library is of course compliant with Python 3.8.