What steps will reproduce the problem?

Attempting to run the one-line debugger call: import pdb; pdb.set_trace() does not start the debugger.

It results in an exception like this:

> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bdb.py", line 48, in trace_dispatch > return self.dispatch_line(frame) > File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bdb.py", line 67, in dispatch_line > if self.quitting: raise BdbQuit >BdbQuit

What is the expected output? What do you see instead?

It would be very handy if this would start the debugger in the/a console that started the devappserver2 process.

What version of the product are you using? On what operating system?

0.5.2/Mac OS X 10.8

Cheers

Are you trying to debug the development server or your application? Where did you insert those code lines that you mentioned?

I think that I understand better: you entered the pdb comments in the interactive console with the idea that you could step through your applications code from there?

Hi Brian, thanks for the reply and sorry I wasn't clear.

The import pdb; ... is in application code, and it starts an interactive console allowing one to step through the code. There's no reason it couldn't "step up" into the debugger, but that wasn't my intention when posting the question so much as debugging a thread of an application.

I hope that clarifies!

Yes, I understand what you want to do now. But it isn't going to work due to the design of the Python runtime in devappserver2; sys.stdin and sys.stdout are pipes connecting the runtime to the devappserver2 parent process.

We should have a better debugging story but it might take us a while to get there.

Thanks for accepting.

As a matter of interest, I have a the highest regards for the Werkzeug debugger http://werkzeug.pocoo.org/docs/debug/ - and operates in an environment fairly analogous to the development appserver. While not strictly on point, it would fall under the rubric of a "better debugging story" :)

Issue 40 has been merged into this issue.

I can't stress enough the importance of having a working debugger. I'm afraid the average developer won't use this devserver until they can debug their code, regardless of any other feature it could have. Could you provide any insight of how long it will take to fix this? In the meantime I'm forced to return to the original devserver and I'd prefer not to. Thanks, and good work

I've started working on this and have written up a description of how I expect it to work: https://docs.google.com/document/d/1CCSaRiIWCLgbD3OwmuKsRoHHDfBffbROWyVWWL0ZXN4/edit?usp=sharing

While pdb doesn't work, I have a prototype that works with Komodo IDE, PyDev, PyCharm. I would expect that Winpdb would work as well but I haven't tested it.

Feedback welcome!

I should add that the document that I linked in my last message is meant for tool providers, not end users. Hopefully tool provides will provide integration using these hooks without any the user have to know how they work.

We have hooks in place to make it possible to add debugger support. It is up to tool vendors now to make use of them.

So your proposal is to make people re-write the core python debugger to work with App Engine?

Thanks Brian. Sorry for the delay in giving feedback. The proposed debugger is a very cool concept.

This issue as posted relates to console/pdb debugging, and it isn't clear to me how one would take advantage of the proposed concept from the command line.

I think a lot of developers (including myself) who use Vim and Emacs also tend to be command-line oriented, and we still seem to be without a viable debugging option.

The tool command line users would take to is almost certainly pdb. We won't see a pdb patch for GAE, but I am hopeful someone can graft something together on top of this concept.

All that said, the concept is great and I hope it can be manipulated so that it can be taken advantage of from the command line.

Since this issue relates specifically to the command line, and that remains an outstanding issue, we may see duplicate issues posted - it may be useful to leave the issue open until there is a command line tool someone can point to.

Cheers

I tried to implement Brian's document recommendations. Managed to get logging in a remote debugger console, but still no breakpoints. Exact account of what I did in here: http://goo.gl/XRU01

I'd like to second @Michael.Kariv on his recent post. I'm having an almost identical experience. Find my exact steps on (text after the 'EDIT:'). http://stackoverflow.com/questions/16149813/unable-to-debug-dev-appserver-in-google-app-engine

I think this issue should be reopened - especially since the sample code in Brian's document is specific to PyDev - which don't work!!! PyDev seems to be the canonical debugger/IDE for Python (most traffic in SO, and #1 recommendation in many questions).

Is I said in my description in SO, I'm able to verify that the --python_startup_script is called, I am breaking to the remote debugger within the runtime process, I am able to step out from my script to runtime.py (main function), and breakpoints to work within the main function. However, putting a breakpoint in my handler will not work. I cannot imagine how do you imagine us working without a debugger.

Another approach could be to monkey patch pdb/ipdb so that they stash the App Engine stdin/out streams before displaying the prompt and restore them when the user hits enter. I'd be totally cool with app.pdb.set_trace() instead of import pdb; pdb.set_trace().

Even better would be to bundle Werkzeug, but let's not get distracted by more difficult endeavors - whatever is quicker.

Just for information: Pycharm 2.7.2 allow debugging on new SDK.