Improve remote debugging tooling
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 11
- Forks
- 39
- Avg merge
- 18d 18h
- Merged PRs (30d)
- 1
Description
Problem
Couldn't run remote debugging (aka, set breakpoints inside the running server code) with the instructions provided by the README.
Context
I followed the steps in the README for debuging functional tests but it didn't work.
After some research + trial-and-error, I was able to make it work with:
# Setting the breakpoint in the code
# I've relied on the already exposed 12345, which I don't know if have another purpose
import epdb; epdb.serve(port=12345)
# Attaching pdb from another terminal
# from here: https://github.com/ionelmc/python-remote-pdb#usage
sudo dnf install rlwrap socat
rlwrap socat - tcp:127.0.0.1:12345
But still, epdb doesn't have a very good documentation and is unmaintained in years.
Proposal
I'd like to have better builtin support for remote debugging out-of-the-box.
The idea I have for this is using remote-pdb, which has slighly better documentation and tooling. For example, it can be configured via envvars to integrate with regular breakpoints(). oci-env could set those envvars by default and we don't have to worry about porting and can use normal breakpoints() syntax.
Alternatives
- Continue using epdb and update README instructions
- Look another tool with convenient remote-debug capability and update README
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the README's “debugging functional tests” section and compare its epdb instructions with the issue's working remote-pdb example. Investigate how oci-env configures functional-test containers and how remote-pdb environment variables integrate with breakpoints(). Done means remote debugging works out of the box and the README documents the complete workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100