Remote debugging support

[virtuald]

trafficstars

Possibly leverage eclipse/pydev support for this? Depends on #26

[virtuald]

I was able to launch a remote debugger using a patched version of pydevd (https://github.com/fabioz/PyDev.Debugger/pull/39). It works pretty nicely.

The way I envision this to work is the user will need to install pydevd on the roborio via the installer, and we'll include a special module that automatically sets up the PATHS_FROM_ECLIPSE_TO_PYTHON variables to map back to the users robot source directory for wpilib and the robot code itself.

[virtuald]

I think the easiest way to go about this has two pieces:

• Create a new remote debug entry point to hal-base for robot programs, and execute that code there
  • See http://robotpy.readthedocs.io/en/stable/dev/design.html#adding-options-to-robot-py
  • Default entry point is at https://github.com/robotpy/robotpy-wpilib/blob/master/hal-base/hal/main.py#L10
• Add a flag to pyfrc's deploy that cause that entry point to be used instead of the default
  • It could accept flags/environment variables that set the MY_PATHS_FROM_ECLIPSE_TO_PYTHON list

[auscompgeek]

I think this could be a good bug for a newcomer to work on if they wanted to delve into how RobotPy works under the hood.

[ThadHouse]

With upstream WPILib moving to VS Code for the 2019 season, it might be worth looking into how remote debug works there. There are some docs going about how to do this. https://code.visualstudio.com/docs/python/debugging#_remote-debugging

[virtuald]

That does look pretty straightforward, thanks for pointing it out :+1:

[auscompgeek]

Huh, that looks so much simpler than pydevd.

I imagine that there will be a number of teams who prefer to use PyCharm over Visual Studio/VSCode though, so we should definitely also consider supporting both ptvsd and pydevd in the long term.

Just to be painful though, PTVS requires different versions of ptvsd than vscode-python, so installing it by default will probably be a bad idea.

Dunno how many people actually use PTVS though. (I imagine that number would be fairly small, but shouldn't mean we should aim to be IDE-agnostic.)

[auscompgeek]

Note: We'll probably want to distribute ptvsd/pydevd with the Cython extensions.

[virtuald]

I think that makes sense. I'd be in favor of distributing a vscode-compatible install by default, but make other configurations possible. Not sure how that would work quite yet though.

[auscompgeek]

Looks like the VS Code plugin supports newer versions of ptvsd nowadays, so we should be ok to package up the latest stable release.

[auscompgeek]

I've started to pick up the VS Code extension again. Would be nice to have a deploy option that calls ptvsd.enable_attach() before the robot code starts.