Amsterdam-Music-Lab / MUSCLE

An application to easily set up and run online listening experiments for music research.
https://www.amsterdammusiclab.nl/
MIT License
4 stars 1 forks source link

Config: Add `debugpy` support and update Docker configuration #1356

Open drikusroor opened 2 weeks ago

drikusroor commented 2 weeks ago

Integrate debugpy for remote debugging and adjust Docker settings to facilitate its use, including necessary configurations in the Dockerfile and Docker Compose. It will allow you to do remote debugging from VS Code, using the Python and/or Python Debugger extensions.

It adds a Docker image variant for the backend; the debug image. You can (temporarily) configure your docker-compose.yaml file to use this image instead of the base image (here). This image starts up a debugging server on port 5678 next to the Django server (that runs on port 8000).

Then, with the use of the (now un-ignored by .gitignore) launch.json file, you can attach VS Code to the debugging server that is now running on 5678.

In one of the backend's python files, place a breakpoint() somewhere where you want the code execution to break. Start VS Code's debugging by pressing F5 on your keyboard and open the part of the MUSCLE application that executes the code where you placed a breakpoint. In my case, I added a breakpoint to the next_round method in session/views.py (1). The frontend clearly cannot load the next round yet (the code execution is interrupted):

image

My VS Code then allows me to resume code execution (2), step in/out of deeper executions, or allows me to see local and global variables(3):

image
drikusroor commented 1 week ago

I'm personally fine with just using vanilla pdb, but anything that makes dev life easier is certainly worth adding. I do hope there's a way to add this without having to adjust the docker-compose file every time we want to run the debug server. BTW, I would expect the current state of docker-compose.yaml (i.e., having the backend image set to base and calling the debugpy function) to not run?

That's right, the debugpy server won't run by default in this scenario. Although we could configure it like that, I think it would cause an unnecessary performance hit / resource hog to the dev environment.