Fix travis CI - #218
Conversation
This helps guard against accidentally catching the wrong error. Now `grep "pytest.raises([a-zA-Z]*)" nengo_loihi -R` reveals only one `AssertionError` with no corresponding message.
|
I think we should be doing the |
|
Wait why do we even |
|
Yeah, I thought I remembered Intel trying to fix that, though I don't ever remember them conclusively saying they did. But if it works without it for 0.8, then let's just get rid of it. We can probably drop support for pre-0.8 by this point. It was definitely necessary with some earlier version. |
No longer necessary in more recent nxsdk versions.
drasmuss
left a comment
There was a problem hiding this comment.
Added a commit to drop support for nxsdk<0.8.0, as well as updating the installation instructions and testing against 0.8.1. With that, this LGTM!
Update installation instructions Update hardware script to test against 0.8.1
The first commit makes our
pytest.raiseschecks more strict. This is something I was using to debug, and isn't strictly needed by this PR, but IMO is a good thing to do.The second commit localizes the
os.chdirto be within atry-finallyblock. This avoids a really weird issue we were seeing as a part of #217 (e.g., see this job and look fornengo_loihi/hardware/tests/test_allocators.py::test_block_size).Essentially... if an error happens when the model is being built, then the current working directory (cwd) is permanently changed. More specifically, an error occurs within
HardwareInterface.__init__, and so__exit__is never invoked. As a result, the directory is never changed back. This only occurs for--target loihi, and causescoverage.xmlto be written to the wrong directory. Part of what made this issue weird is thatcoverage.xmlis only written to the wrong directory if-nis omitted, but not for-n 1. This may be a subtle aspect of how pytest spins up its workers.The second commit also adds a check to pytest's setup/teardown to make sure the directory is not changing. This test would fail on
test_block_sizewith--target loihiif it were not for the fix.Note this does not solve #217 (i.e., it does not make
nengo-loihiprocess safe). The issue explained in the commit message of e9cd851 is still present. Solving this is outside the scope of PR.