Also observing a very bizarre behavior where if there are actual Errors (like a ValueError) triggered within one of the test functions (see PR #106 that fixes the ones I'm seeing), they aren't grabbed within the try/except of run_checks and included in the report, but instead are raised to console as true errors:
but if I don't include the --config dandi they behave as expected and go into that extra section of the final report.
Steps to Reproduce
From a console with working directory located in a folder that has dandiset 000004 (or ros3, alternatively)...
nwbinspector ./000004 --config dandi
and compare to...
nwbinspector ./000004
Traceback
Screenshot in the first section; particulars of the traceback don't really matter, it's the fact that it IS a traceback pushed to the console as the standard out instead of getting grabbed by the report.
[X] Have you ensured this bug was not already reported?
[X] To the best of your ability, have you ensured this is a bug within the code that checks the NWBFile, rather than a bug in the NWBFile reader (e.g., PyNWB or MatNWB)?
What happened?
Also observing a very bizarre behavior where if there are actual Errors (like a
ValueError
) triggered within one of the test functions (see PR #106 that fixes the ones I'm seeing), they aren't grabbed within thetry/except
ofrun_checks
and included in the report, but instead are raised to console as true errors:but if I don't include the
--config dandi
they behave as expected and go into that extra section of the final report.Steps to Reproduce
Traceback
Operating System
Windows
Python Executable
Python
Python Version
3.9
Package Versions
versions.txt
Code of Conduct