I'm using Flask 0.9 with Python 2.7.1 within a virtualenv, and starting my app with foreman start
In other apps I've built when I add the following line to my app:
import pdb; pdb.set_trace()
then reload the browser window, my terminal window displays the pdb interactive debugger:
(pdb)
However in my app when I add those lines nothing happens. The browser window hangs and shows a constant state of loading yet nothing shows in the console.
Is there some magic that needs to happen?
This is because you're using Foreman, which captures the standard output.
To debug your app with pdb, you'll need to "manually" run it, using python app.py or whatever you use.
Alternatively, you can use WinPDB (which, despite the name, has nothing to do with the operating system), which will let you remotely debug a Python process. You can even use it when the program is running on another server.
Related
After following the steps in the official wiki I keep getting the following error when launching with breakpoints or setting breakpoints:
/ptvsd/wrapper.py", line 423, in pydevd_request
os.write(self.pipe_w, s.encode('utf8'))
File "google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime/stubs.py", line 40, in os_error_not_implemented
raise OSError(errno.ENOSYS, 'Function not implemented')
OSError: [Errno 38] Function not implemented
The application runs anyway but the breakpoints are never hit. It seems that ptvsd is trying to use some method that is blocked by the app engine sandboxed environment. I'm running vscode in a python virtualenv, any clue?
My solution was to use PyCharm community edition's debugger, its similar perhaps more capable IDE and debugger for Python specific debugging.
I have tried to find a reliable way to get rid of this error but it's proving quite difficult. Here are some advices though:
Use the --threadsafe_override=default:false flag when running the app engine dev server as explained here.
The app engine dev server must be launched from vscode(for example via a task) instead of a separate terminal window.
If you still get the error, stop the debugger, kill the task and restart everything.
(After that the debugger correctly hits the breakpoints, but curiously the callstack is set to the main thread instead of the thread containing the breakpoint, you need to manually click on the correct thread in the callstack window.)
I'd like to develop a Bokeh application and based on the documentation, it seems best to run the bokeh serve --show app.py locally when developing the application.
After running the command, the application launches in a new browser tab and works correctly. However, it's not clear to me how to edit the code and rerun the application because once the tab is closed, the application continues to run in the terminal and the only way to exit is through kill <pid> which is somewhat inconvenient.
What is a good workflow for developing a Bokeh application?
If you are on a mac, you can stop the application with ctrl+c from terminal. This will shut down the app. Then you edit the code, save it and rerun bokeh serve --show app.py from terminal. That's all.
Note that the application should continue running as long as your browser window is open. If you change the inputs using the widgets in your dashboard it will print out logging in terminal, as it updates the dashboard according to your code.
Closing the tab will only close the client session. To kill the server process, indeed you need to kill the process somehow. Ctrl+c is convenient from the terminal. If you are in an IDE like PyCharm, I suggest setting up your configuration to run bokeh like a python script via python -m bokeh serve --show. Then you can use your IDE's start/stop/restart functionality also.
FYI if you are in Pycharm 2017.x, your script name should be the script or directory (for directory-based apps) of the bokeh app and interpreter options should be -m bokeh serve --show
I typically also set up another configuration for debugging which runs the script like a typical python script (no special interpreter args). This will allow you to use your IDE's debugger for any issues basically up to the initial page load. For any debugging beyond that (i.e. callbacks), I typically use a combination of logging and/or manual pdb.set_trace() calls.
I'm using Pycharm 4, with flask 0.10.1, python 3.4
It seems that when running a flask application from inside pycharm, if I run it with:
app.run(debug=True)
My breakpoints are ignored. After some googling, I've found that in order to make PyCharm stop on breakpoints, I should run flask with:
app.run(debug=True, use_reloader=False)
Now PyCharm correctly stops on breakpoints, but I miss the autoreloading feature.
Is there any way to make both work together?
Using python 2.7 both things work
I reported this to PyCharm: https://youtrack.jetbrains.com/issue/PY-13976
I'm going to start with the short answer: No, what you want cannot be done with any releases of PyCharm up to 4.0.1.
The problem is that when you use the reloader the Flask application runs in a child process, so the PyCharm debugger is attached to the master process and has no control over the child.
The best way to solve this problem, in my opinion, is to ask Jetbrains to build a "restart on change" feature in their IDE. Then you don't need to use Werkzeug's reloader at all and you get the same functionality direct from PyCharm.
Until Jetbrains decides to implement this, I can share my workaround, which is not terribly bad.
In the "Edit Configurations", set the configuration you are going to use to "Single Instance only" (check box in the top right of the dialog box)
Make sure the configuration is the active one.
Configure your Flask app to not use the Werkzeug reloader.
Press Ctrl-D to start debugging (on Mac, others may have a different shortcut)
Breakpoints should work just fine because the reloader isn't active.
Make any code changes you need.
When you are ready to restart, hit Ctrl-D again. The first time you do it you will get a confirmation prompt, something like "stop and restart?". Say yes, and check the "do not show again" checkbox.
Now you can hit Ctrl-D to quickly restart the debugger whenever you need to.
I agree it is not perfect, but once the Ctrl-D gets into your muscle memory you will not even think about it.
Good luck!
I found that in PyCharm 2018.1.2 there is FLASK_DEBUG checbox in run configuration:
With this after making some changes, saving file triggers reload action.
In my setup, I'm debugging the flask app by running a main.py file which sets some configuration and calls app.run(). My python interpreter is set up in a Docker container.
My issue was that I needed to check Run with Python console.
The problem is because with use_reloader=True the werkzeug application is started in a seperate (child) thread of main application and PyCharm fails to correctly handle breakpoints because they are lost when the thread starts.
You can try to follow this thread: http://forum.jetbrains.com/thread/PyCharm-776 but it seams there was not too much progress on that.
I'd suggest using something Python-ish like pdb, i.e.:
#app.route('/<string:page>')
def main(page):
import pdb; pdb.set_trace() # This line actually stops application execution
# and starts Python debug shell in the console
# where you can examine current scope and continue
# normal code execution at any time.
# You can inject *any* code here.
# For example, if you type `print page` during pause,
# it will output content of "page" variable.
return render_template('index.html')
Try configuring this python running configuration in "Edit Configurations". After that, run in debug mode.
You need to unlock the console.
you start the app in debug mode
then you make something that causes an error.
at the end of the error message from flask is this
Here you enter the PIN flask prints in the console at the start
copy paste this pin into the console and click confirm PIN
now the breakpoints will work
from pycharm 2017 using python 2.7 (in my case with virtual env, but I suppose not necessary) I do:
run...
leave scripts and scripts parameters blank
I put in interpreter options: -m flask run
set the env variables FLASK_APP
than run attach to local process, and finally choose the running process
my use case is to connect from postman to flask rest services endpoints and interrupt on my breakpoints
To debug a bug I'm seeing on Heroku but not on my local machine, I'm trying to do step-through debugging.
The typical import pdb; pdb.set_trace() approach doesn't work with Heroku since you don't have access to a console connected to your app, but apparently you can use rpdb, a "remote" version of pdb.
So I've installed rpdb, added import rpdb; rpdb.set_trace() at the appropriate spot. When I make a request that hits the rpdb line, the app hangs as expected and I see the following in my heroku log:
pdb is running on 3d0c9fdd-c18a-4cc2-8466-da6671a72cbc:4444
Ok, so how to connect to the pdb that is running? I've tried heroku run nc 3d0c9fdd-c18a-4cc2-8466-da6671a72cbc 4444 to try to connect to the named host from within heroku's system, but that just immediately exits with status 1 and no error message.
So my specific question is: how do I now connect to this remote pdb?
The general related question is: is this even the right way for this sort of interactive debugging of an app running on Heroku? Is there a better way?
NOTE RE CELERY: Note, I've now also tried a similar approach with Celery, to no avail. The default host celery's rdb (remote pdb wrapper) uses is localhost, which you can't get to when it's Heroku. I've tried using the CELERY_RDB_HOST environment variable to the domain of the website that is being hosted on Heroku, but that gives a "Cannot assign requested address" error. So it's the same basic issue -- how to connect to the remote pdb instance that's running on Heroku?
In answer to your second question, I do it differently depending on the type of error (browser-side, backend, or view). For backend and view testing (unittests), will something like this work for you?
$ heroku run --app=your-app "python manage.py shell --settings=settings.production"
Then debug-away within ipython:
>>> %run -d script_to_run_unittests.py
Even if you aren't running a django app you could just run the debugger as a command line option to ipython so that any python errors will drop you to the debugger:
$ heroku run --app=your-app "ipython --pdb"
Front-end testing is a whole different ballgame where you should look into tools like selenium. I think there's also a "salad" test suite module that makes front end tests easier to write. Writing a test that breaks is the first step in debugging (or so I'm told ;).
If the bug looks simple, you can always do the old "print and run" with something like
import logging
logger = logging.getLogger(__file__)
logger.warn('here be bugs')`
and review your log files with getsentry.com or an equivalent monitoring tool or just:
heroku logs --tail
I have pydev on eclipse and would like to debug handlers. I put breakpoint on a handler and start project in debug mode. When I click on the hyperlink corresponding to handler the control does not come back to breakpoint. Am I missing something here?
Also the launch is for google app engine application in python.
I'm using eclipse with PyDev with appengine and I debug all the time, it's completely possible !
What you have to do is start the program in debug, but you have to start the dev_appserver in debug, not the handler directly. The main module you have to debug is:
<path_to_gae>/dev_appserver.py
With program arguments:
--datastore_path=/tmp/myapp_datastore <your_app>
I hope it help
The simplest way to debug is to use the builtin python module pdb and debug from the shell.
Just set the trace in the handler you want to debug.
import pdb
pdb.set_trace()
How do U run the server, from within the eclipse or from the shell. If it is from the shell, then how does eclipse know you are even running the application;
You could use an user friendly version of pdb, ipdb that also includes user friendly options like auto complete.