Debugging Python bottle apps with WingIDE - python

I'm writing an Python Bottle application (Python 2.7.2 and Bottle 0.10.9) and developing it in the WingIDE (3.2.8-1) Professional for Linux. This all works well, except when I want to debug the Bottle application. I have it running in standalone mode within WingIDE, but it won't stop at any of my break points in the code, even if I set Bottle.debug(False). Does anyone have any suggestions/ideas about how I can setup Bottle so it will stop on breakpoints within WingIDE?

If you have the reloader set to true bottle starts a subproccess for the actual app. In Wing you need to turn off the reloader, then it should work.
run(reloader=False).
But you will have to restart the app in wing every time you make changes.

Are you debugging under WSGI using wingdbstub.py or launching bottle from the IDE? I'm not that familiar with bottle but a common problem is a web framework's reload mechanism running code in a sub-process that is not debugged. I'm not certain bottle would do that under WSGI, however, but printing the process id at time of importing wingdbstub (or startup if launching from the IDE) and again at the line where the breakpoint is missed would rule this in our out. The "reloader" arg for Bottle.__init__ may be relevant here. If set to True, try setting it to False when debugging under Wing.
Another thing to try is to raise an exception on purpose where the breakpoint is (like "assert 0, 'test exception'" and see if this exception is reported in Wing's debugger in the Exceptions tool and if so whether Wing also manages to open the source code. If bottle is running code in a way that doesn't make it possible to find the source code then this would still stop on the assertion (Wing's debugger stops on all assertions by default even if the host code handles the exception) but it would fail to show the debug file and would put up a message in the status area (at bottle of IDE screen and in the Messages tool) that indicates the file name the debug process specified. Depending on this it may be possible to fix the problem (but would require modifying Bottle if the file name is something like "".
BTW, to insert code that is only run under Wing's debugger us something like this:
import os
if 'WINGDB_ACTIVE' in os.environ:
# code here
If this doesn't help please email support at wingware dot com.

Related

How to debug a Splunk application with pdb?

How can I spawn a pdb-like debugger in a Splunk application (meaning: an application made for and ran by Splunk) ?
I have no control over the python process itself, so simply putting import pdb; pdb.set_trace() in the code will just result in the web app crashing.
I guess the ideal solution would be to
either run the python part of Splunk manually, so I have control over it (I tried this, but it didn't work correctly; mongodb daemon wasn't starting, among other things)
use the good old import pdb; pdb.set_trace() breakpoint but attach to the process somehow, so I'm able to manipulate the debugger (I tried gdb, but nothing worked as expected -- perhaps I didn't use it correctly)
One way to debug might be a remote debugger, like remote-pdb.
It behaves similar as pdb. You can set a breakpoint, then configure the interface and a TCP port where the debugger will listen.
from remote_pdb import RemotePdb
RemotePdb('127.0.0.1', 4444).set_trace()
After that you can simply connect to the debugger using telnet telnet 127.0.0.1 4444
More info:
https://pypi.org/project/remote-pdb/

PyCharm docker debugging error

SEE EDITS
I'm trying to get the latest version of PyCharm to successfully debug Django running inside Docker. However I'm having trouble setting up the remote python interpreter and I get an error as soon as I try to start the debugger.
Can't run remote python interpreter: com.github.dockerjava.api.exception.InternalServerErrorException: {"message":"the working directory 'C:/Program Files (x86)/JetBrains/PyCharm 171.2613.10/jre64/jre/bin' is invalid, it needs to be an absolute path"}
The path, in my eyes looks pretty absolute, so I'm guessing its something else. I'm not even sure who or what is causing the error. The docker container (because of the JSON response) or PyCharm.
Running
PyCharm 2017.1
Docker for Windows (docker version 1.13.0)
Any thought of what I might be missing/having problem with?
Edit
Forgot to include my settings from PyCharm on how I set up the remote interpreter.
I get no errors with the above settings
Edit 2
It looked like the "Django project root" had accidentally been set to the incorrect path above. So that is fixed. My problem now is that when I run the Run/Debug Configuration it tries to start the server again, which is already running inside the docker container. Is there no way to attach to the already running python process?
Edit 3
I've now managed to get a "success" message when starting the debugger (PyCharms Python Remote Debugger) and starting the server after. However I seems like the debugger stops listening after 1 second (or less). My theory is that the debugger looses connection after it has passed the pydevd.settrace() function call. I have placed the following code (of the top of my head) at the bottom of manage.py:
sys.path.append('pycharm-debug.egg')
import pydevd
pydevd.settrace('192.168.1.100', port=21000)
What am I missing?
EDIT 4
After investigating further I now seem to successfully connect the debugger on server startup. However, if the pydevd.settrace(....) function call is present the server never actually starts. The startup seems to freeze/stop on python manage.py runserver 0.0.0.0:8000. As soon as I remove the settrace line. The server starts without issue. Any ideas?
I also get this message when the server is starting:
warning: Debugger speedups using cython not found. Run '"/usr/local/bin/python" "/usr/local/lib/python3.5/site-packages/setup_cython.py" build_ext --inplace' to build.
The problem is that I can't run the command listed in the message because the file setup_cython doesn't exist.
You're right! It really don't start the runserver process, but I believe it's not because isn't working, but because it is.
See, when you successfully connected the pydevd settrace with the debugger server you had to configure on PyCharm it already worked, at least it worked for me.
I believe the reason runserver isn't working is because the warning created by the missing cython is stopping the debugger, the only thing you have to do is tell it to keep running and jump that warning clicking on the green right-pointing arrow to do so.
PS.
I'm debugging a django application running on docker (docker-machine), the host IP, in that case is 192.168.99.1
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "helpdesk.settings")
from django.core.management import execute_from_command_line
sys.path.append('pycharm-debug.egg')
import pydevd
pydevd.settrace('192.168.99.1', port=3000, stdoutToServer=True, stderrToServer=True)
execute_from_command_line(sys.argv)
Hope I helped!
I have the same quesiton
I had solved it by editing the pycharm Interpreter
you can add some config to the "Path mappings" as follows
before the "=" , write your local code path
after the "=" , wirte your cloud server code path
Interpreter-config.png
I only change this, it works!!!
Hope that can help you~

How to debug Python script which is automatically called inside a web application?

I'm developing a cassandra storage finder for graphite-api.
graphite-api is installed via pip and run via gunicorn so I can't just call the script with a debugger but want to use interactive debugging.
When I import pdb in my storage finder and set a breakpoint, the code will halt there, but how can I connect now to the headless running pdb in the script?
Or is my approach to this debugging problem the wrong one and this has to be done in a completely other way?
pdb gives control over to gunicorn, which is not what you want. Have a look at rpdb or other remote debugging solutions.

Python/Flask: Application is running after closing

I'm working on a simple Flask web application. I use Eclipse/Pydev. When I'm working on the app, I have to restart this app very often because of code changes. And that's the problem. When I run the app, I can see the frame on my localhost, which is good. But when I want to close this app, just click on the red square which should stop applications in Eclipse, sometimes (often), the old version of application keeps running so I can't test the new version. In this case the only thing which helps is to force close every process in Windows Task Manager.
Will you give me any advice how to manage this problem? Thank you in advance.
EDIT: This maybe helps: Many times, I have to run the app twice. Otherwise I can't connect.
I've faced the same problem and solved it. I think it may help.
When we run a flask based site locally it is assigned to a TCP port: 5000 and the Default IP: 127.0.0.1:5000
Sometimes TCP connection remains even after closing the program or terminating the code. So, The idea is kill the TCP connection. You can do it from command-prompt(cmd)
Two Steps to Follow:
1. See the Process ID(PID) for the running TCP connection.
Go to cmd and type:
netstat -ano
Kill The Process By PID. Command for this: taskkill /f /im [PID]. Example is showed bellow.
taskkill /f /im 7332
I've had a very similar thing happen to me. I was using CherryPy rather than Flask, but my solution might still work for you. Oftentimes browsers save webpages locally so that they don't have to re-download them every time the website is visited. This is called caching, and although it's very useful for the average web user, it can be a real pain to app developers. If you're frequently generating new versions of the application, it's possible that your browser is displaying an old version of the app that it has cached instead of the most up to date version. I recommend clearing that cache every time you restart your application, or disabling the cache altogether.
This actually shouldn't happen with the latest versions of PyDev (i.e.: since PyDev 3.4.1: http://pydev.org/history_pydev.html, PyDev should kill all the subprocesses of the main process).
So, can you check which PyDev version are you using?
If you're in the latest version of PyDev, you can use Ctrl+Shift+F9 to terminate/relaunch by default.
But as you're dealing with flask, you should be able to use it to reload automatically on code-changes without doing anything by setting use_reloader=True.
I.e.: I haven't actually tested, but its documentation says that you can set the reload flag for that run(use_reloader=True) -- and PyDev should even be able to debug it (I'll take a better look and improve the PyDev docs on that area later on).

python testing server-deployed application

I've got a small application (https://github.com/tkoomzaaskz/cherry-api) and I would like to integrate it with travis. In fact, travis is probably not important here. My question is how can I configure a build/job to execute the following sequence:
start the server that serves the application
run tests
close the server (which means close the build)
The application is written in python/CherryPy (basic webapp framework). On my localhost I do it using two consoles. One runs the server and another one runs the tests - it's pretty easy and works fine. But when I want to execute all this in the CI environment, I fall in trouble - I'm unable to gain control after the server is started, because the server process waits for requests... and waits... and waits... and tests are never run (https://travis-ci.org/tkoomzaaskz/cherry-api/builds/10855029 - this build is infinite). Additionally, I don't know how to close the server. This is my .travis.yml:
before_script: python src/hello.py
script: nosetests
src/hello.py starts the built-in CherryPy server (listens on localhost:8080). I know I can move it to the background by adding the &: before_script: python src/hello.py & but then I shall find the process ID in the CI-environment and kill the process which seems very very dirty solution and I guess there's something better than that.
I'd appreciate any hints on how can I configure this.
edit: I've configured this dirty run in the background and then kill the process in this file. The build passes now. Still, I think it's ugly...

Categories