-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[BUG] Rich traceback not working proprely within notebook #2271
Comments
Hello, we have the same issue, has anyone found a way to avoid this? |
It appears as though by the time the traceback is displayed, Jupyter has removed the temporary file it created There's been no relevant changes in Rich, so it looks to me like Jupyter has changed behaviour here. I think the best fix may be for Jupyter to ensure that the code isn't removed from the filesystem until after the traceback handlers is run. There may be a workaround, which I'm considering. And that would be to snapshot the code at the time of the exception. But that is not without other potential issues. |
Yeah indeed it looks like a Jupyter problem. Unfortunately as jupyter lab and notebook are widely adopted especially in ML I tend not to use the rich traceback anymore because it will break in notebook. We had to remove from DocArray because of this. If they were any solution even hacky one we would probably bring back the rich traceback |
There doesn't appear to be any way to workaround this in Rich. The paths reported in the traceback don't exist, so there is no way to get the relevant code. I've reported this issue to the Jupyterlab repo. |
IIRC instead of using the files directly, Rich could/should use the linecache module. This is also where IPython and/or ipykernel writes to. |
An excellent example on how to use linecache is the traceback module in the CPython distribution. |
Not sure that would help, since Rich needs the entire file to do Syntax highlighting. |
each notebook cell is written to a 'file', which may not exist on disk, but is in the linecache module, see where it gets written to |
so, |
Ah, well that explains a lot. Thanks. I can use that to workaround the issue. Although I'm not keen on the implementation in ipython. The |
I agree, but seeing it being used in traceback.py and ipython, I thought this was probably poured in concrete a long time ago. |
I hope we solved your problem. If you like using Rich, you might also enjoy Textual |
Thanks for the explanation @maartenbreddels Tracebacks are fixed in 13.1.0 (just released). |
great news thanks ! |
Great, fix looks nice, glad I could help! |
Just popping on here to say that this issue was killing me for a few days... I had no idea this package existed, my jupyter just randomly broke. |
Describe the bug
When the rich traceback is enabled in a notebook, the traceback is almost unreadable and show a criptic message:
Here is a screenshot that showcase the issue with a very simple traceback.
One could say that there is no point of activating the trackback from inside a notebook. However the problem persist when importing a library that enable rich traceback. (Ex in my case
docarray
orjina
)thanks in advance for any support 😃 !!
Platform
Click to expand
Linux, running from jupyter notebook
The text was updated successfully, but these errors were encountered: