[BUG] pdb/breakpoint() isn't very usable during progress

[The-Compiler]

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.

[willmcgugan]

Setting breakpointhook is an interesting idea. It would have to wrap whatever is already there so it doesn't break pdb.

My only issue with that is debugging changes what's being debugged. Might be fine if you are debugging some unrelated code, but if you are debugging anything related to the progress bar or what it renders, it's going to change things.

I wonder what other TUI libraries do.

[The-Compiler]

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.

[willmcgugan]

That might be useful, bit I don't think it would help you much in the case of Live / progress. I think the reason you are not seeing input is that the thread to refresh the progress bars is still active. You could try auto_refresh=False on track, that should prevent the refresh thread from running.

[littlebeat23]

Spam

…

On Thu, 25 Feb 2021, 1:58 am Will McGugan, ***@***.***> wrote: Setting breakpointhook is an interesting idea. It would have to wrap whatever is already there so it doesn't break pdb. My only issue with that is debugging changes what's being debugged. Might be fine if you are debugging some unrelated code, but if you are debugging anything related to the progress bar or what it renders, it's going to change things. I wonder what other TUI libraries do. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1053 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARR3REMBWMY7BFZDXQWVY3DTAU46BANCNFSM4YEVBQZA> .

[willmcgugan]

Closing because I can’t think of a good solution, but it’s something I’m thinking about. Going to be doing more work in the area.

[The-Compiler]

Alright - feel free to tag me if you need feedback or testing for something!

[jacobian]

I ran into this the other day as well, and was surprised by it as well. I worked around it by just removing the progress bars while debugging and then adding 'em back once I figured it out. I'd love to see a solution here as well (but agree that a good one seems elusive).

[willmcgugan]

@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.

[d-chambers]

I ran into this as well. Is there an easy way to disable the refresh thread?

[supersergiy]

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.

[yohan-pg]

Could this be reopened? This is a complete dealbreaker if you use breakpoint()

[DanCardin]

For my own purposes, setting force_terminal=False makes rich stop doing fancy output and causes breakpoint/pdb to function correctly. Which obviously only works if you're debugging the actual code and not the rich output, but that's good enough for me.

[yohan-pg]

For my own purposes, setting force_terminal=False makes rich stop doing fancy output and causes breakpoint/pdb to function correctly. Which obviously only works if you're debugging the actual code and not the rich output, but that's good enough for me.

I'm not too familiar with rich in general, this is an argument to rich.console.Console? Do you have an example of using this with track?

[DanCardin]

as far as I know every rich construct accepts a Console, and something like the original statement of rich.progress.track is just a shorthand for rich.progress.Progress().track, where Progress accepts a console, and would otherwise be using a default console.

I'd guess that setting TERM=dumb environment variable would have the same effect, if your code wouldn't be amenable to threading Console objects around.

Either way, its essentially just forcing rich to act as it would inside a pipe or whatever where it wont output its fancy control codes. Which obviously isn't helpful if you're debugging rich output, but my own purposes were debugging my own code which just happened to be running in a context where rich was causing the described issues. And my guess would be most of the time/people in this thread are in the same boat.

[MatthiasZepper]

A solution that works for ninnies like me is using a pipe when debugging instead of fiddling with the rich.progress.Progress code or environment variables. Since Rich detects the pipe, it omits all the eye candy and at least pdb.set_trace() works like a charm. Conveniently, you get a free log on top if you pipe to tee instead of cat/tail.

my_cli_tool_with_rich buggy_command --some param | tee output.log