The current approach of just having multiple Python elements fails, because Travis puts each Python installation into its own private virtualenv. As a result, tox can't see them all, and so fails.
This PR changes Travis to use a "matrix" build - each Python version is run as a separate build, and tox is run in each, with TOXENV set to that Python version.
I took the liberty of adding Python 3.5 and 3.6 to the test matrix. Also, the tests fail on Python 2,6, because subprocess.check_output doesn't exist in that version. It's probably possible to fix that, but I don't know if pipsi formally supports Python 2.6. Personally, I'm inclined not to do so, but that's not really my call.
The current approach of just having multiple Python elements fails, because Travis puts each Python installation into its own private virtualenv. As a result, tox can't see them all, and so fails.
This PR changes Travis to use a "matrix" build - each Python version is run as a separate build, and tox is run in each, with
TOXENV
set to that Python version.I took the liberty of adding Python 3.5 and 3.6 to the test matrix. Also, the tests fail on Python 2,6, because
subprocess.check_output
doesn't exist in that version. It's probably possible to fix that, but I don't know ifpipsi
formally supports Python 2.6. Personally, I'm inclined not to do so, but that's not really my call.