-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mypy exited with status 1 - no error messages shown #120
Comments
Hey there! Thanks for the report 👍 At a glance, the |
Sorry, I misread, please disregard the below. If I run without -x, the output is printed, but that's because the mypy run for the offending file is run, fails, and produces the error. I'm still getting only
|
I needed to debug that issue which occurred only on my CI server, so I added more detailed output to the |
I have some type errors in my code, and would like to find them by running mypy via pytest-mypy. When I run pytest, I get:
This suggests that there were some errors, but it doesn't show what they were, so I cannot fix them. Running mypy separately reveals a bunch of issues in
proof_of_concept/rest/registry_client.py
.Looking at the pytest-mypy source, it seems that this can happen if mypy checks a file that has not been collected. I'm importing the problem file from the file under test, and mypy gives a bunch of errors about this imported file. I guess the
::mypy
test passes anyway, because the errors are not in the file under test. However, pytest-mypy then generates an error using this secondmypy-status
result, because mypy returned a non-zero exit code.Ignoring the errors makes sense I think, they should show up later when the problem file itself is tested. Unfortunately, we never get to that point, because I'm running with -x, which stops the tests as soon as the first error is found, and no error messages are shown for the
mypy-status
failure, so I cannot fix them.I'm a bit confused about the current intent of the pytest-mypy code. There's a comment suggesting that the
::mypy
test is intended to fail even if mypy only shows errors in files that weren't collected, and that that is why there's the::mypy-status
result. On the other hand, there used to be a test that checked that no MypyStatusItem was created unless there was at least one MypyFileItem, which I think means the opposite. That was removed in cd459a4 however, which also introduced this-status
result.In my opinion, a mypy failure only because of errors in imported files should either be considered an error in the file under test, in which case the error should be printed, or it should not be considered an error in the file under test, in which case all tests related to that file should pass and the non-zero exit code ignored. The latter makes more sense to me.
The text was updated successfully, but these errors were encountered: