With regards to
tox, the presence of tox.ini is a good indicator that
tox is what is wanted, however that only always holds true if there is a single travis python job, or if envvar
TOXENV is set. If there are multiple python jobs, it is quite likely that the
tox.ini is intended for developers to run locally in order to test multiple python versions, and isnt suitable for travis to be invoking in each job, and running
tox in Travis will often fail in that scenario.
However, travis could install
tox-travis [COI: I am one of the maintainers] to make tox choose the correct testenv to correspond with the Travis python version in each job. If Travis doesn’t want to depend on tox-travis, the alternative is to set TOXENV (if not already set) to
pypy3, etc. It is a fairly simple string transform from
TOXENV for the most common cases.
Fairly common now, but worth noting that the latest tox version does not support py2.6, py3.0-3.3 and may also fail on 3.8-dev (at least in py37 early dev cycle it didnt handle this, but maybe that has been fixed), and tox-travis also doesn’t support those versions either. You would need to go back a long way in the tox version history to find a version which worked with py3.3 or py2.6, and may not even find a version which supported py3.0-2 . pytest is roughly the same in this regard. tox-travis did have some special voodoo to keep py3.2 and 3.3 supported after
tox killed them, but that was discarded in tox-travis v0.11.