pudb icon indicating copy to clipboard operation
pudb copied to clipboard

Automatically start the script, like pdb with (-c continue) option?

Open diadochos opened this issue 7 years ago • 11 comments

Hi, I am wondering if it is possible to automatically start running the program when calling PUDB by -m option of python, just like in PDB.

diadochos avatar May 22 '18 07:05 diadochos

That sounds reasonable. I'd be happy to take a patch that does that.

inducer avatar May 22 '18 10:05 inducer

It's not clear if this issue is about being able to run modules with main function (e.g. pudb3 -m module.name, which will be added in https://github.com/inducer/pudb/pull/390) or about the pdb -c "debugger script" feature.

I don't really see the need for a debugger script -c feature for pudb case, to be honest, since 1) it's a graphical debugger 2) it already saves breakpoints. But maybe I'm missing something.

eliasdorneles avatar Jun 23 '20 14:06 eliasdorneles

I think the -m comment here is just @diadochos mentioning that he uses python -m pudb to start pudb (as opposed to set_trace()).

I agree that supplying commands to pudb maybe doesn't make sense, but having a command line option to give the equivalent of set_trace(paused=False) could be useful.

asmeurer avatar Jun 24 '20 02:06 asmeurer

I've love to see this feature. Whether by pudb -m or pudb script.py or whatever, it would be nice to launch my script with pudb ready to go without having to hit c at the start (and without having to add set_trace to my application's startup). It's minor, but it would really suit my workflow; whenever I trigger my "run" in vim it takes a few seconds for the terminal to launch and pudb to start before I can hit c just so the tests or app start running. It would be nice to remove that papercut.

HappyEinara avatar Sep 14 '21 09:09 HappyEinara

so something akin to pu.go? Since that exists, seems like this should be relatively easy.

Edit: I take that back, this would have to operate in a very different way than pu.go, if I've read the related code correctly.

mvanderkamp avatar Sep 14 '21 22:09 mvanderkamp

In principle I think that's right though. A CLI switch that would set paused=False when running a script or module from the pudb command (or python -m pubd). In other words: the option of set_trace(paused=False), or pu.go, which is available when hooking into pudb from application code, should also be available when launching a program by running pudb from the cli.

HappyEinara avatar Sep 26 '21 21:09 HappyEinara

Any idea on where to start with something like this?

benjamin-kirkbride avatar Aug 25 '22 00:08 benjamin-kirkbride

One trick to get started might be to trigger a traceback in DebuggerUI.interaction() just to see what the stack looks like the first time that function is hit.

mvanderkamp avatar Aug 29 '22 03:08 mvanderkamp

Or actually adding a ui_log.warn('foo', stack_info=True) line might be more clear.

mvanderkamp avatar Aug 29 '22 03:08 mvanderkamp

I find it very useful to be able to skip or automate the initial 'c' keypress, especially when debugging the same script over and over again.

Until this feature is added ~~I am using this as a workaround~~ Update: this works only if there are no breakpoints, so it is not useful.

cat <(sleep 1; echo "c") | python3 -m pudb myscript.py

The cat sends a c keypress to the part after the pipe. I had to add the sleep 1; part because otherwise it resulted in strange errors. You can experiment with different sleep values. I hope this helps someone.

The above solution is not really working, maybe someone knows a better commandline hack :)

And I would very much like to have a commandline option for this.

kwmiebach avatar Sep 17 '22 16:09 kwmiebach

I've taken a stab at this in #559, though I went for a specific --continue option instead of a general -c <command> option. Does that seem reasonable?

mvanderkamp avatar Sep 25 '22 22:09 mvanderkamp