Closed ReenigneArcher closed 2 months ago
We do not format things as tables.
The exception output you see comes directly from python itself. I think this table-like output was introduced in python 3.11 with the addition of exception groups, but could also be added in 3.12. I am not 100% sure. They improved error stuff over the last version more than once.
AFAICT the error is indirectly cause because of a bash code block inside one of the files you lint. When we encounter a code block with a language we support, we write the content of the code block to a temporary file, which in turn gets check by different external tools depending on the language and we then consume the error messages and print them to the user if any. In your case you can see in the top section for the 8th file this line result = self._run_in_subprocess(source_code, ".bash", ["bash", "-n"])
showing me that a bash code block is being tried to lint via bash -n <tempfile.bash>
in a subprocess. I am unsure if maybe the tempfile cannot be found. Or maybe that the bash executable cannot be found on your system, which seems more likely to me in this case because you are on windows.
Unfortunately I cannot test this myself, because I work in linux and have no windows machine to test on.
I use python a lot, including 3.11 and have never seen tracebacks formatted in a table.
This is the specific issue... We cannot determine which file is having the issue.
[cmake] | | files = [ | |
[cmake] | | WindowsPath('C:/Users/frog/Desktop/Sunshinà | |
[cmake] | | ]
This could be easily fixed by handling the FileNotFound exception. Print the file you are expecting to find, then exit with the original exception. Would you accept a PR to at least handle the exception a little better?
PEP 654 added ExceptionGroups to python 3.11 which have a similar format like your output. But your output does not contain "ExceptionGroup" so that's not it.
You can see the format with a simple snippet like this:
try:
raise AssertionError
except* AssertionError:
raise
Actually I found the culprit: typer
the CLI lib I use for rstcheck and since v0.5 they format errors like this. And you can disable the pretty output with the environment variable _TYPER_STANDARD_TRACEBACK=1
Generally I am open to PRs, but I am unsure how to handle it differently in a way which would not clutter the output. But I am open to ideas.
you can disable the pretty output with the environment variable
_TYPER_STANDARD_TRACEBACK=1
Awesome, I will try that!
Edit: this removes all the relevant info about the files it couldn't find.
To Dos
[X] I have checked the issues and think that this is not a duplicate.
[X] I added a very descriptive title to this issue.
Description
The traceback is difficult to read when formatted as a table. We have a complaint of a missing file and cannot determine which file is missing.
Operating System
Windows
Operating System Details
No response
Python Version
3.12
rstcheck Version
6.2.1