rich: [BUG] pdb/breakpoint() isn't very usable during progress
Describe the bug
When calling breakpoint() during progress, the pdb prompt doesn’t echo typed characters. Thus, it’s not really possible to debug anything in the code running while progress is shown.
I suppose rich could set sys.breakpointhook to first get the terminal out of raw mode when breakpoint() is used?
(This is probably somewhere between bug report and feature request)
To Reproduce
import time
import rich.progress
for n in rich.progress.track(range(5)):
time.sleep(0.5)
if n == 3:
breakpoint()
Platform Arch Linux, Kitty
Diagnose See #1052.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 15 (2 by maintainers)
Could this be reopened? This is a complete dealbreaker if you use breakpoint()
I do not believe this issue can be marked as resolved. Currently,
rich.progressinfluences the debugging process of the user codebase.With a custom breakpoint hook, the user would expect the trace to be set at frame
sys._getframe().f_back. Using a wrong frame will cause great confusion for the user. Thus it is impossible to overridesys.breakpointhookwhile respecting what is already there, because what’s already there may not take in a frame as input – evenpdb.set_tracedoes not. The only way is to do it is to disrespect what’s already there, and use:It is a tough ask to expect each
richuser to know how to do this correctly.@jacobian Only thing that occurs to me is to disable the refresh thread if the debugger is active. That’s probably good enough, assuming you didn’t want to debug the progress bars themselves.
Perhaps as a compromise, there should be a manual escape hatch? If I could blindly type
rich.reset()or whatever and then go on with debugging, I suppose that’d work - though it’s not particularly discoverable, I guess.