Using pudb as an API

[sucrecacao]

Hello,

I would like to use pudb as an API, to integrate it with my favorite editor kakoune.

I was wondering if there is a way to use it more or less like this:

file_to_debug = pudb.load('foo.py')

# adding breakpoint to line 3 of foo.py
file_to_debug.add_breakpoint(3)

# being able to use command next, continue and step into 
file_to_debug.continue()     # should stop at the next breakpoint ( line 3 ) 

# being able to retrieve data from the right side panel 
file_to_debug.get_variables()    # getting all variables loaded at line 3
file_to_debug.get_stack()

[inducer]

Are you planning on making use of pudb's UI? If not, you're probably better off building on bdb, which is debugging functionality built into Python's standard library. pudb is built on that, too. If you are planning on making use of the UI, then pudb.debugger.Debugger inherits from bdb.Bdb and is vaguely compatible with it.

[sucrecacao]

My dream would be to use the kakoune editor as the 'Code' panel and put the right size panel in a separate tmux pane, as the Comand line panel ( maybe use ipython for this one )

[lieryan]

For adding breakpoints, you can modify the breakpoint file from your editor. I have a small python script that does this to integrate with vim: https://github.com/lieryan/vim-pudb/tree/remote-pudb/plugin

The only minor issue here is that you can only modify a breakpoint file while pudb isn't running. If pudb is running when you modify the breakpoint file, pudb won't see the new breakpoints, and it'll overwrite your changes when pudb exits.

What I think would be nice here is if pudb watches its breakpoint file for changes and reloads the breakpoints if it's modified while it's running.

[mm40]

@lieryan Actually, you can modify a breakpoint file while pudb is running, but as soon as the file is modified, press ctrl+r in pudb. That will call reload_breakpoints function, which will reload breakpoints from the file. Note : newly added breakpoint will only be visible in Breakpoints frame, but the corresponding line will not be highlighted in the code frame. Despite this, newly added breakpoint will actually work, meaning the execution will stop at the corresponding line. Similarly, when breakpoints are deleted from breakpoints file, and reload_breakpoints is called via ctrl+r, they are in fact deleted from breakpoints list, but corresponding lines in code frame are still highlighted (if they were in the first place). In other words, breakpoint highlighting is out of sync, but breakpoints work perfectly fine.

Automatization of sending ctrl+r to PUDB:

1. Terminal in which pudb will be ran, should have PUDB_NAME title set. For xterm treminal emulator : xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T PUDB_NAME
2. Send key shortcut to that terminal via xdotool search --name PUDB_NAME windowactivate --sync %1 key Ctrl+r windowactivate $(xdotool getactivewindow)

Maybe @inducer knows :

1. Is function reload_breakpoints meant to be used by user at all, by pressing ctrl+r, since this shortcut is not documented, or was this shortcut meant to be used by developers of this project for debugging only?
2. If that shortcut to call reload_breakpoints is meant to be used by user, (and it is very useful for us, who are externally modifying the breakpoints file), is it a bug that newly added breakpoints in the file are only visible listed in the Breakpoints frame, but not highlighted in the code frame? Also, it should be documented in list of shortcuts then?

[inducer]

I'm not sure I have thought about reload_breakpoints that carefully, but I'd be happy to see it become a first-class (documented) citizen that also properly updates the source window. PRs welcome.

[mm40]

@inducer I hope #436 represents a step towards naturalization.