Enhacements: simplify Travis-CI configuration using tox and enable running same tests locally

[ssato]

This is another trial to add tox.ini to yamllint (previous one is pr #313).

This PR consists of the commits do followings.

1. Add tox.ini and requirements.txt for pip: This is similar to pr enhancement: make possible to run tests and related stuff using tox #313 but also should enables that developers can run almost same tests running in Travis-CI locally.
2. Simplify Travis-CI configuration utilizing tox.
3. Optional change to do similar CI using GitHub Actions instead of Travis-CI to reduce risk of strong dependency to specific CI web service only.

[ssato]

FYI. Here are some example CI results after these changes are made.

• Travis-CI: https://travis-ci.org/github/ssato/yamllint/builds/726334830
• GitHub Actions: https://github.com/ssato/yamllint/actions/runs/250085771

[adrienverge]

Thanks @ssato, I've carefully reviewed your PR, it looks good, but as stated in #313 I prefer to keep the repo as simple as possible for non-Pythoners, non-tox-users.

[ssato]

Very sorry to bother you but could you please let me clarify what do you mean by "to keep the repo as simple as possible for non-Pythoners, non-tox-users" ?

Firstly, I don't understand who that simplicity of the repo for you intend to. As I noted tox is not for ordinal users, maybe non-Pythoners, who just want to install yamllint using pip or something, use it and maybe never look at this repo. Tox is purely for developers who want to fix and/or improve yamllint code and test it in isolated and clean environments to avoid specific issues because of their environments. Yamllint is written in python, so, inevitably, developers know python and how to use tox somewhat, I guess. Also, because you embed the several steps to test yamllint code into .travis.yml which is not fully consistent with the steps explained in CONTRIBUTING.rst, it's not simple for developers including me to test modified yamllint code in an isolated and clean environment or environments in which multiple different versions of pythons are installed consistently. In other words, the simplicity of the repo by not adding just a few small files you're particular about does not bring any benefits for such developers, IMHO.

Next, tox is not a minor tool, AFAIK. It seems popular enough and adopted in many python oss projects already. For example, flask, jinja2, click, scrapy, certbot look using it. I don't insist that all python developers know and familiar with tox but guess that many python oss developers have seen it in other oss projects and have used it before perhaps. Also, some developers (non-tox-users) can choose not using tox and run the testing steps in CONTRIBUTING.rst manually. For this, I splitted the change into some commits on purpose.

[adrienverge]

Very sorry to bother you but could you please let me clarify what do you mean by "to keep the repo as simple as possible for non-Pythoners, non-tox-users" ?

Sure, I mean to have as few non-required files as possible, and also as few external tools/dependencies as possible, so it's easy for a new beginner to understand in which file to start. I feel that CONTRIBUTING.rst is simple and consistent, but feel free to propose suggestions.

test it in isolated and clean environments to avoid specific issues because of their environments

This applies to many Python projects, but do you have a problem example for yamllint? This project has very few dependencies (2), hence should hardly depend on the users environments.

Yamllint is written in python, so, inevitably, developers know python and how to use tox somewhat, I guess.

If you look at PRs in this project, you'll see that quite a few were written by non-Pythoners (some were their first writing of Python code!)

Next, tox is not a minor tool, AFAIK. It seems popular enough and adopted in many python oss projects already.

I've used tox for years and I know how useful it is for projects like OpenStack, Flask, etc.
It's on purpose (simplicity to understand the repo) that it's not in use in this small and simple project.

[ssato]

Thanks for your quick response! I really appreciate you have taken time for all of my proposals.

test it in isolated and clean environments to avoid specific issues because of their environments

This applies to many Python projects, but do you have a problem example for yamllint? This project has very few dependencies (2), hence should hardly depend on the users environments.

My own problem is that I cannot test it after my modifications made easily with just single command (like 'tox -e py36) instead of a series of commands, e.g. virtualenv ...; source .... /bin/activate; ...; python setup.py test, in my development environment before submitting PR. I'm running Fedora for my daily work and hacks in my spare time and Fedora should not be so popular compared to others like macOS and ubuntu, AFAIK, so I want t make sure that I did not bring any regressions or issues because of my modifications before I submit PR and the CI service letting me know about it.

[bristea]

My own problem is that I cannot test it after my modifications made easily with just single command
Is not your unique problem, I would say that almost anyone that is able to edit Python code knows what tox is and how to use it. IMHO, Yamllint would become far more welcoming for PRs if it would have a tox file, not the other way around.