Hi everyone! 👋 Our startup is looking to switching our whole code base to use Pants. One issue we’ve been having is that we’ve been unable to figure out the correct way to get the debugger to work for FastAPI. I created a sample project here to give an example of what we’re trying to do. When I run

./pants run --debug-adapter src/python/greeter/main.py

, I can successfully connect through

Python: Remote Attach

in Visual Studio Code. However, when I set a breakpoint on line 9 of

/src/python/greeter/main.py

and try to visit

localhost:8000/

in my browser, the breakpoint is never activated. I see output in both my terminal and the debug console but the breakpoint is just never activated. Any help would be greatly appreciated, thanks!

cc @bitter-ability-32190, since alas I am not too familiar with VS Code, more of a PyCharm guy (but I do know how to get remote debugging working on that IDE…)

It's been a bit since I worked on this, so bear with me. Two things come to mind: • File paths have to roughly match. I remember some issues with paths when I was implementing and testing the feature. Are you using source roots? • Debugpy has verbose logging. You can add --debugpy-args=... And pass extra flags to debugpy (I'll look up the flags when I'm on desktop)

@bitter-ability-32190 No problem! I tried explicitly adding source roots here and it still looks like it is not working for me. I’m new to Pants so I’m not sure if I configured everything properly

It should be pretty plug-n-play

Gotcha, so does that mean you were able to get it to work and I made a mistake in my project config?

No, it's shortcoming of the Pants code

@bitter-ability-32190 For sure, I will include a link to this slack thread Pardon my ignorance, but is what you’re saying is that by default Pants tries to use a sandbox (temporary directory) and that is what is causing path issues in this case for VS Code debugging?

Yup! You got it. Eventually we plan to swap the default

Maybe docs update and a blog post, instead of memory? 🙂

Well when time permits I'd rather just find out if we can cajole debugpy into doing it right in the sandbox too 😛

For now, let's publish whatever allows people to be productive, even if it's not perfect. We can publish the more optimal solution when it's available, but let's not sit on a solution that's minimally viable.

Well since I'm likely doing the work, might be worth just making it work first. Then blogging about it later. After all I love me some coding

Meantime, a quick update to the docs? A tip box or something?

@busy-vase-39202 Not sure if it’s helpful at all, but that was the case for our team. Since our team is smaller, the code base is relatively young, and the majority of our team uses VS Code, it was a big sticking point for us to decide if we should migrate to Pants if we couldn’t use our existing debugging workflow. We almost decided not to, but then we were able to find this solution and we are greatly relieved.

Early next year I'm hoping to get to spend much more time on making VS Code + Pants very friendly