This section describes how to set up debugging with wingdbstub on a a remote host. In Wing Pro, these instructions are needed only if you cannot launch your code from the IDE using a remote host configuration. For example, if your code runs under a web server or as an embedded script in a larger application, you need to use wingdbstub to debug your code. In other cases, setting up a remote host configuration is a much easier way to debug your code remotely. See Remote Hosts for details.
If you do need to use wingdbstub to a remote host, first consider installing Wing on the remote host and using remote display of the IDE via X Windows (Linux/Unix) or Remote Desktop (Windows). This is typically easier than following in the instructions here.
When this is not an option, use the following steps to set up remote debugging with wingdbstub (and see also the Remote Debugging Example):
(1) First set up Wing to successfully accept connections from another process within the same machine, as described in section Importing the Debugger. You can use any Python script for testing this until you have values that work.
(2) Optionally, alter the Server Host preference to the name or IP address of the network interface on which the IDE listens for debug connections. The default server is None, which indicates that the IDE should listen on all the valid network interfaces on the host.
(3) Optionally, alter the preference Server Port to the TCP/IP port on which the IDE should listen for debug connections. This value may need to be changed if multiple copies of Wing are running on the same host.
(4) Set the Allowed Hosts preference to include the host on which the debug process will be run. For security purposes, Wing will reject connections if the host isn't included here.
(5) Configure any firewall on the system that Wing is running on to accept a connection on the server port from the system that the debug process will run on.
(6) Next install Wing on the machine on which you plan to run your debug program. Creating an entire Wing installation is the easiest approach. Alternatives are to copy only the debug server code out of a Wing installation on the same type of OS or to compile the debugger core from source code. For details, see Installing the Debugger Core.
(7) Next, transfer copies of all your debug code so that the source files are available on the host where Wing will be running and at least the *.pyc files are available on the debug host.
During debugging, the client and server copies of your source files must match or the debugger will either fail to stop at breakpoints or stop at the wrong place, and stepping through code may not work properly.
Since there is no mechanism in Wing for transferring your code, you need to use NFS, Samba, FTP or some other file sharing or file transfer mechanism to keep the remote files up to date as you edit them in Wing.
If files appear in different disk locations on the two machines, you will also need to set up a file location map, as described in File Location Maps.
(8) On your debug host, copy wingdbstub.py into the same directory as your source files and import it in your Python source as described in Debugging Externally Launched Code.
(9) If you didn't copy wingdbstub.py out of a complete installation of Wing on the debug host, you will need to set WINGHOME in your copy to match the location where you have copied the debug server code on your debug host.
(10) In wingdbstub.py on your debug host, set kWingHostPort. The host in this value must be the IP address of the machine where Wing is running. The port must match the port configured with the Server Port preference on the host where Wing is running.
(11) Then restart Wing and try running your program on the debug host. You should see the Wing debugger status icon change to indicate that a debug process has attached.
If you have problems making this work, try setting kLogFile variable in wingdbstub.py for log additional diagnostic information.