pytest-watch with debugger

[Glueon]

Quite often I invoke pytest with the --ipdb option so I could see what is wrong with my code on first failure.

So I invkoed pytest-watch with ptw -- --ipdb. The problem is that if after droping into ipdb I modify a test or a file it starts a new session and the one with ipdb console goes to the background. In the end I end up with dozens of ipdb instances running.

Is it possible to block ptw if current session has dropped to the ipdb?

[joeyespo]

That's an interesting case. I think that'd be a good thing to handle.

Any idea how pytest works with --ipdb? Namely, does the pytest process remain running until the debug session is over? (I would think it does.) If so, it might be worth adding an --ipdb argument that gets forwarded to pytest and also signals to ptw to wait for the process to finish.

What do you think, @Glueon?

[Glueon]

Yes, pytest keeps running when it is in the ipdb.

I do not know if a forwarded --ipdb option is a good solution, because py.test can be dropped into debugger from code with something like import ipdb; ipdb.set_trace().

But I think you can just block ptw in all cases untill pytest finishes. Then --ipdb forwarding will be redundant.

[joeyespo]

Yes, pytest keeps running when it is in the ipdb

Excellent.

because py.test can be dropped into debugger from code with something like import ipdb; ipdb.set_trace()

Ah, very true. Good point.

But I think you can just block ptw in all cases untill pytest finishes

I thought about that initially before replying. The downside is then you sacrifice the feature of cancelling a long-running testsuite when you save a file. It's a nice feature of ptw so you don't have to wait for the tests to finish before running them again with the latest code.

Another approach would be to add a --wait / -w argument to tell ptw to wait for cases like this. (I'm sure --ipbd won't be the only one.)

[Glueon]

I think -w approach is better. If someone relies on cancellation functionality you won't break anything introducing it.

[aldanor]

It may also make sense to suspend any pytest re-runs until the currently running pytest process has finished (although the events can still be collected / spooled). Maybe just make that a default option to avoid yet another command line arg.

[joeyespo]

It may also make sense to suspend any pytest re-runs until the currently running pytest process has finished

@aldanor I personally work on some bigger projects with long-running test suites. The cancelling behavior is really nice in these cases since it nearly doubles the time running tests, which can be significant. But you're right, it'd be best to not introduce an option if we can avoid it. I wonder if there's a simple cross-platform way to detect whether py.test is running vs ipdb / something else. That would make running tests cancellable, but wait on child / spawned processes.

If there's no other option, I think I'd still prefer cancel-by-default over a new CLI argument. Have any other ideas?

[joeyespo]

Question for you. If signal.SIGTERM is sent to a Python process in a debug session, will it terminate or keep running until you explicitly exit with a command?

[joeyespo]

If signal.SIGTERM is sent to a Python process in a debug session, will it terminate or keep running until you explicitly exit with a command?

For reference, with --pdb, it terminates your debugging session after you enter a command.

[joeyespo]

Fixed with 18a99b8, which adds --wait. (This was enabled by 0cf6b93, which ensures only one instance of pytest is running, and 6e07f80, which gracefully terminates a test run with KeyboardInterrupt which --wait overrides.)

Just published v4.0, which includes these changes. Feel free to re-open if there's still an issue!