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)

Most upvoted comments

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.progress influences 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 override sys.breakpointhook while respecting what is already there, because what’s already there may not take in a frame as input – even pdb.set_trace does not. The only way is to do it is to disrespect what’s already there, and use:

pdb.Pdb(sys._getframe().f_back).set_trace()

It is a tough ask to expect each rich user 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.