Make the tests work on Windows #213
Conversation
|
Looks like there is a problem with me renaming (on Windows) the "err" script to "err.py". In doing so, I guess the execute bit got lost as Windows doesn't have one of them. A "simple" solution would be for someone to fix this on Unix and leave it at that, but doing so might mean that if a Windows user ever changed that file in future, it would get broken again. I'll try a more robust fix that runs the command using the Python interpreter directly. |
… executable bit being set
|
@bitprophet That was a lot easier than I expected. This PR patches up the tests to make them work on Windows (mostly by skipping the pty-related ones, plus a few small tweaks to commands that don't work the same on Windows) and adds support for running on Appveyor. To enable Appveyor testing all you need to do is sign up for the Appveyor free plan using your github account, then do "Add project", select github and pick this project. Once added, builds will run automatically. Appveyor is phenomenally slow, because the free plan has pretty limited resources (mostly it's just that you wait for workers for a long time - when the tests finally run they run about as fast as Travis). I'm testing Python 2.7, 3.3 and 3.4 (32 and 64 bit) as those are the ones Appveyor has installed by default. You can add more just by downloading and installing the extra versions of Python yourself, but IMO it's not worth the effort. Actually, Appveyor has found a bug for Windows - Python 3.3 chokes trying to read /etc/invoke which doesn't exist (looks like some issue in core python importlib, which has presumably been fixed in 3.4). At some point, invoke should get its config from a more appropriate location on Windows but I'll see if I can find a short-term patch in the meantime. |
|
Actually, the "Python 3.3 bug" seems to be that you're using I'll raise a separate issue for this - its not something that should be bundled in with this PR... |
| eq_(result.exited, 127) | ||
| if WINDOWS: | ||
| # Windows doesn't give a 127 error for "unknown command" | ||
| assert result.exited != 0 |
There was a problem hiding this comment.
Does the actual numeric result vary or something?
There was a problem hiding this comment.
I think it's just 1, but I couldn't be sure it's the same everywhere (Windows doesn't have a tradition of well-defined "system-level" exit codes like this). So I just left it as non-zero as a safe option. I'm happy enough to say "equals 1" and fix it later if that's too specific.
There was a problem hiding this comment.
Don't care super hard, was just curious, thanks.
pfmoore
force-pushed
the
windows_tests
branch
5 times, most recently
from
50f78c7 to
c21c06d
Compare
|
OK, this is now ready to go. The tests fail on Windows without #215 but that's an independent issue hence the separate PR. |
|
Confirmed tests still run OK on my end. Thanks! EDIT: Shoot, wrong ticket, that was 215. El oh el. However, the tests for this branch ALSO pass so yay for that. |
Make the tests work on Windows
|
FTR I just set up AppVeyor under my own (Github) account. Seems to be running now, will see how it completes (I just did some big ol refactoring, so...). Obviously, in some cases where the Windows breakage isn't obvious/trivial, I won't be able/willing to actually dig into stuff - but at least now I'll know, and ostensibly Windows users will be able to view the build status so you know you're not off your rocker if things are breaking on your end. |
|
@bitprophet if there are windows issues, feel free to ping me and I'll see what I can do to assist. |
|
Of course, appreciated. Just saw aforementioned refactor did break things in one test, already applied fix. Fun times. EDIT: also, you weren't kidding about slow :D good thing this is all semi-optional for me, I can just ignore it and check again later. |
Getting the tests to work on Windows wasn't as hard as expected. Mostly by skipping the ones that weren't obvious :-) I may have broken some of the tests on Unix, posting this PR for Travis to check...