Use pdb with green

[ondrae]

Hi, I'm trying to debug a test. I usually inset break points using the pdb library. Green seems to swallow up those break points and skip right over them.

How can I use import pdb; pdb.set_trace() in combination with green tests?

[CleanCut]

Off the top of my head, I have no idea. Green launches the actual tests in one or more subprocesses for scalability reasons, which is almost certainly why you're seeing stuff get ignored. Perhaps there is some way we could make green pass pdb through to a single subprocess to make such a thing work.

I'm open to suggestions!

In the short term, you could just sidestep green and import and run your test functions directly with pdb.

[amitsaha]

This is a deal breaker :( My experience with nose and pdb is often it just hangs where I place the set_trace() function. However, I have always been able to use from nose.tools import set_trace; set_trace() to drop me into a (pdb) shell.. Perhaps you may get ideas from there.

[CleanCut]

That's a great start. I'll see what they did.

I also have a coworker who has done some interesting things with remote-debugging with pdb, so I now know it's definitely possible to attach a debugger to an arbitrary process...somehow. I'd love to give this enhancement a shot once I finish addressing the outstanding issues.

[pior]

Same here with ipdb. It is indeed a deal breaker.
I've always used ipdb directly with nose.

[suned]

+1

[gleopoldo]

+1 Same issue.

Have you guys any solution about this one inside green?

[CleanCut]

I never have made it to researching this one. If anyone has already figured something out with pdb, please let me know as I would love to use your experience as a starting place for making this work.

[gleopoldo]

I'm comming from ruby community, so I'm not experienced with python, and less with pdb itself. However, I've seen some approaches using ruby's Fibers to control thread execution on collaborative ways, allowing us to stop a running thread, do something with it, and then resume it's execution. I think that some debugging engines, like byebug already uses that. Do you think that we can take such approach in green?

[alexandrebarbaruiva]

Man, I'd really love to see this feature on green! Currently I'm using invoke to not run django tests with green when there's an ipdb breakpoint

[alexandrebarbaruiva]

@CleanCut I looked at nose.set_trace() and noticed that they restored the sys.stdout, does green change the default stdout? I know nose is very old by now, but maybe it helps me understand what's going on

Copying and pasting the code for easy referencing:

def set_trace():
    """Call pdb.set_trace in the calling frame, first restoring
    sys.stdout to the real output stream. Note that sys.stdout is NOT
    reset to whatever it was before the call once pdb is done!
    """
    import pdb
    import sys
    stdout = sys.stdout
    sys.stdout = sys.__stdout__
    pdb.Pdb().set_trace(sys._getframe().f_back)

https://github.com/nose-devs/nose/blob/master/nose/tools/nontrivial.py#L73

[CleanCut]

@alexandrebarbaruiva Yes, Green captures stdout by replacing saving and replacing the value of sys.stdout and then sets sys.stdout back to its original value before and after every test (unless the user specifies -a/--allow-stdout). If altering sys.stdout at runtime is a blocker to using pdb, then an option for enabling pdb could force-enable -a/--allow-stdout. This all applies to sys.stderr as well.

You should also note that Green has the additional complication that it coordinates the entire run in a main process, but actually runs tests in a subprocess (actually N subprocesses, where N is the number of logical cores by default).

I would naively guess that enabling pdb support in Green would involve restricting the number of test-running subprocesses to 1 (which could easily be done at argument-parsing time) and then finding a way to connect to the one subprocess which is actually running the tests.

[CleanCut]

@alexandrebarbaruiva A couple comments about this code:

def set_trace():
    """Call pdb.set_trace in the calling frame, first restoring
    sys.stdout to the real output stream. Note that sys.stdout is NOT
    reset to whatever it was before the call once pdb is done!
    """
    import pdb
    import sys
    stdout = sys.stdout
    sys.stdout = sys.__stdout__
    pdb.Pdb().set_trace(sys._getframe().f_back)

1. stdout = sys.stdout creates a variable named stdout and then throws it away without using it, which is very odd.
2. When python starts, sys.stdout and sys.__stdout__ are the same value. So either one of those values is changed by code elsewhere in nose (which is probably what is going on -- I haven't taken the time to investigate), or sys.stdout = sys.__stdout__ also does nothing.
3. That docstring doesn't speak to why sys.stdout is not being reset once pdb is done. I inferred from your comment that you believe that resetting sys.stdout may break something with pdb. That is certainly a possibility. Another possibility is that it has nothing to do with whether pdb functions correctly or not, but they simply hadn't found a way to reset it in the end. In that case, the comment is simply a red herring with respect to getting pdb to work with Green.

In any case, I welcome further investigation and/or work towards enabling using pdb! 😄