Support Windows

[rmcgibbo]

I think I still had a problem running asv gh-pages from windows, but this fixes some of the major issues.

[pv]

Is this necessary? The range spec is supposed to be a single argument passed to git.

[rmcgibbo]

Oh, I have been using this to run a single commit with asv, like asv run "-1 <hash>", since git log will take more than one argument.

[pv]

Indeed, git rev-list indeed appears to not accept single arg spec.. ("hash1 ^hash2" and so forth). There's a single-commit notation too "hash1^!", though.

[pv]

Does the test suite pass? Did you also check if the peakmem benchmarks work? When I wrote it https://github.com/spacetelescope/asv/blob/master/asv/benchmark.py#L128 worked, but would be useful to check that again now that it has a chance of being actually used.

[pv]

Otherwise, looks great to me. @mdboom: could be useful to use appveyor to run tests on windows

[mdboom]

There are systems that don't have setpgid that are still Unix-like and can still use select. It looks like you've changed the behavior here so anything that doesn't have setpgid doesn't use select (and thus can't provide feedback that the subprocess is running). Can you fix the logic here so we only fall back to proc.communicate on Windows?

[mdboom]

I would like to set up Appveyor as part of this PR ideally so that this work doesn't get undone in the future. Thanks for setting this up, @rmcgibbo.

[mdboom]

#281 adds Appveyor support. Before merging this PR, we should base it on that one and make sure all the Appveyor tests pass etc.

[rmcgibbo]

It seems like there is a bug somewhere with the terminal colors using colorama. When I run the tests under python setup.py test, it turns the whole terminal to black text on black backround, and you can't see anything. Commenting out the import colorama; colorama.init() from asv/console.py fixes it. Since py.test also uses colorama, I assume that somehow it's being invoked twice in a way that messes things up.

[rmcgibbo]

After disabling colorama, here are the results of the test on my windows box. I'm not familiar enough with py.test to know what the error means: https://gist.github.com/rmcgibbo/f053315c620ca9504671

[pv]

The problem probably is that colorama.init() adds some filter to stdout, which pytest doesn't like. You perhaps should do `colorama.init(wrap=False)` on top and explicitly use the colorama AnsiToWin32 stream converter in color_print.

[pv]

Wrong indentation (doesn't do what the original code did) -- only the signal handler part should be inside if posix

[pv]

The colorama.init() doesn't really seem callable twice.
I don't see py.test actually calling it. Instead, they have this:
.
colorama = None
try:
import colorama
except ImportError:
pass
...
if hasattr(file, "isatty") and file.isatty() and colorama:
file = colorama.AnsiToWin32(file).stream

[rmcgibbo]

Okay, I'll try changing it to use the explicit stream

[pv]

The multiprocessing test in `test/test_util.py` seems to hang on Appveyor. Does it pass on your system?

[pv]

Some extra fixes in gh-282 (separate PR to see if appveyor runs)

[pv]

The py.test INTERNALERROR failure is probably https://bitbucket.org/pytest-dev/py/issue/55/broken-comment-parsing; workaround is to pass --tb=native to pytest

[pv]

Ok, managed to clear most of the errors up. There's a weird access denied error remaining in `test_environment.py:test_presence_checks` --- appears on Appveyor, but can't reproduce that on my vm. @rmcgibbo: are you able to reproduce that?

[rmcgibbo]

Using https://github.com/pv/asv/tree/pr-280-windows, I still get black-on-black text in the terminal (powershell or VS command prompt).

[rmcgibbo]

After disabiling colorama, I do not get an error in test_presence_checks though. That test passed fine.

[pv]

I suppose you don't get test_presence_checks errors even with colorama (redirect the output to file if it's black-on-black)? As said, I didn't manage to reproduce these, but they occur on Appveyor.

For me, the output from pytest is colorless, even when colorama is installed. Colors in asv work fine.

[rmcgibbo]

With your branch, colorama enabled (redirecting stdout), I get.

platform win32 -- Python 2.7.8 -- py-1.4.30 -- pytest-2.7.2
rootdir: C:\Users\Administrator\asv, inifile:
collected 33 items

test\test_benchmarks.py ...
test\test_compare.py .
test\test_conf.py ..
test\test_dev.py .....
test\test_environment.py X..
test\test_graph.py ....
test\test_machine.py .
test\test_publish.py .
test\test_quickstart.py .
test\test_repo.py .x
test\test_results.py .
test\test_rm.py .
test\test_subprocess.py ..
test\test_util.py .
test\test_web.py s
test\test_workflow.py ....

======== 30 passed, 1 skipped, 1 xfailed, 1 xpassed in 541.50 seconds =========

[pv]

I'll just drop colored printing on windows, not really worth the trouble trying to debug it.

[rmcgibbo]

+1

[pv]

The "Access is denied" error then seems somehow connected to the setup on Appveyor (I didn't get it with admin user or non-admin users). Not sure what to do about this, I don't know much about windows ACL, so it would be tempting to just mark it as a known failure on windows as it seems it's not encountered in actual use.

[rmcgibbo]

Given that the current master doesn't work at all on windows, and your PR works on both of our machines, it seems like a clear improvement, even with this appveyor issue.

[pv]

The Appveyor access denied failure appears to be due to Python DLL/exe files inside the environment, probably they have remaining open file handles or something that prevents removal. File removal on NTFS is non-POSIX. Adding sleeps, or using the conda.install.rm_rf implementation for rmtree doesn't seem to help, so this doesn't appear to be an intermittent pending-delete failure that can be solved by retrying the operation. Interestingly, the failure only occurs for the combinations where the Python version asv uses is the same as that used in the environment (2.7 in the test); pytest reports it as xpassed (X) when asv itself runs on 2.6 or 3.4 in the Appveyor tests.

I think this failure is fairly unlikely to occur in real use cases --- first, I and @rcmgibbo do not manage to reproduce it on our machines. Second, environment re-creation is not a common occurrence, and when it happens, the Python interpreter inside the environment is unlikely be running. So I think just marking this as xfail won't be so bad in practice.

[mdboom]

Closed by #282.