Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first commit makes our
pytest.raises
checks 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.chdir
to be within atry-finally
block. 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.xml
to be written to the wrong directory. Part of what made this issue weird is thatcoverage.xml
is only written to the wrong directory if-n
is 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_size
with--target loihi
if it were not for the fix.Note this does not solve #217 (i.e., it does not make
nengo-loihi
process safe). The issue explained in the commit message of e9cd851 is still present. Solving this is outside the scope of PR.