Windows and OSX support
jayvdb opened this issue · 5 comments
pglass/tox-pip-version#14 is considering using the alpha Travis Windows, and is probably a good candidate for using tox-travis .
The Windows VMs do start up quite quickly, making it a viable support platform. I tend to only use travis OSX on master builds, as they are so slow to spin up.
Neither Windows or OSX support language: python, but I expect that Python library maintainers will quickly start adding Windows jobs due to the ease and speed of adding specific versions of Python to the Windows VMs. The need for Windows testing is also much higher than for OSX, as OSX usually works if Linux works, while that is rarely the case for Windows.
Also python: 3.6 does "work", in that it shows Python: 3.6 in the job table for the build, and sets the correct envvars.
So it is simple to have jobs which look the same on Windows, with only a little more preparation, and tox-travis could make that even easier.
There was a bit of thought about this at #19 , but that mostly centered on the problem of OSX slowness, which hasnt gone away.
timrburnham/bom_open#21 is an intentionally basic use of Travis Windows with tox-travis.
The job starts almost immediately after the other matrix items are completed, and completes in ~3 mins. Caching of the choco python installer will likely reduce the job time considerably.
For some reason I had thought that the python: 3.6 also wasn't working, so I'm glad to find out it is. Are you finding anything in your implementation that needs to be adjusted in tox-travis to get Windows or OSX to work correctly?
language: python doesnt work on either.
python: x only shows that in the UI, but has no effect, and doesnt set TRAVIS_PYTHON_VERSION, so that needs to be manually set.
As far as I know, there is no way to detect python: x was used, so tox-travis cant help there unless it reads it from the travis build config (.travis.yml or the api json) and extracts the job config by using the job number. You've been reluctant to go down that path previously, and this doesnt feel like it is worth revisiting that decision, as it is fairly simple for the user to set explicitly and soon enough Travis Windows will support language: python.
But if the user needs to set TRAVIS_PYTHON_VERSION for each job , they may as well set TOXENV for each job -- it is shorter, and less of a hack.
The reason I use TRAVIS_PYTHON_VERSION is the x.y format also works as the choco python --version argument, so I am only writing the version twice, instead of three times, and one of those is a web UI only eye candy thing. Ah, also using it in the PATH, but that can be easy fixed.
I havent tried anything fancy - any use of TRAVIS_LANGUAGE will fail, as it wont be python.
And I havent bothered with OSX for a long time -- the builds take too long to start every time I try.
tox-travis could install the correct choco package, and set the PATH ;-)
That would avoid trying to do the crazy travis python versions -> choco package/version mapping in a bash expression.
That would also help for pypy , as the mapping gets harder when they are involved.
Likewise with OSX, doing the brew commands.
@jayvdb thanks a lot for saving me time. I've been wondering why tox doesn't run anything on Windows and MacOS