Python remote debugging

Python remote debugging DEFAULT

Remote Debugging with PyCharm

With PyCharm you can debug your application using an interpreter that is located on the other computer, for example, on a web server or dedicated test machine.

PyCharm provides two ways to debug remotely:

  • Through a remote interpreter.

    Case: Use this approach to leverage extended debugging capabilities available on the remote machine.

    Requirements: SSH access from the local machine to the remote server.

  • Using the Python remote debug server configuration.

    Case: Use this approach to integrate the debugging process into the series of running processes on the remote server. This might be helpful when you cannot explicitly run your application for debugging, or when some preparations tasks are required.

    Requirements: SSH access from the local machine to the remote server, access from the remote server to the local machine using any predefined port.

Before you start

Complete the following preparation tasks:

  1. On the local machine, create a pure Python project, as described in the section Create a Python project.

  2. Add a Python file to this project (- Python File).

  3. Add the following code to the Python File:

    import math class Solver: def demo(self, a, b, c): d = b ** 2 - 4 * a * c if d > 0: disc = math.sqrt(d) root1 = (-b + disc) / (2 * a) root2 = (-b - disc) / (2 * a) return root1, root2 elif d == 0: return -b / (2 * a) else: return "This equation has no roots" if __name__ == '__main__': solver = Solver() while True: a = int(input("a: ")) b = int(input("b: ")) c = int(input("c: ")) result = solver.demo(a, b, c) print(result)

Creating a deployment configuration for a remote interpreter

In this example, the machine where you run your application is referenced as local, and the machine with the remote interpreter is referenced as remote.

Configure a remote interpreter

  1. Ensure that you have SSH access to the remote machine.

  2. Add a new remote interpreter to the project as described in Configure an interpreter using SSH specifying the credentials to connect to the remote machine.

  3. Once you create the remote interpreter for your project, the corresponding deployment configuration is created. To preview it, click to open the Settings dialog window on the local machine, then click the Build, Execution, Deployment node and the Deployment node.

    Deployment configuration
  4. You can accept all default settings or alter them, if needed. For this example, let's use a meaningful name for your deployment configuration, for example, "MySFTPConnection".

  5. Ensure that the Root path value reflects the path specified in the corresponding settings of the created SSH interpreter.

    Path mappings verification

    To check the Path Interpreter in the settings/preferences, expand the list of the available interpreters in , select Show All..., and click Show an interpreter path. The existing paths of the selected interpreter show up in the Interpreter Paths dialog.

Now your deployment configuration is ready.

Deploy your application to a remote host

Next, your application must be deployed to the remote host.

  1. On the menu, select .

  2. File Transfer tool window appears. Verify the number of transferred files.

    File Transfer window

Debug your application

  1. Right-click the editor background and choose the (here ).

  2. Review the debugging output. Note that debugging actually takes place on the specified remote server.

    Debugging on the remote server

Remote debugging with the Python remote debug server configuration

You can also enable remote debugging with the dedicated run/debug configuration, namely, Run/Debug Configuration: Python Debug.

Create a run/debug configuration

  1. From the main menu, choose . The Run/debug configurations dialog opens. You have to click Add configuration on the toolbar, and from the list of available configurations, select Python Debug Server.

    Adding a Python remote debug configuration
  2. Enter the name of this run/debug configuration - let it be MyRemoteServer. Specify the port number (here 12345) and the IDE host name (here 172.20.208.95) of the machine where the IDE is running. These parameters will be used by the remote debug server to access it.

  3. Map the path on the local machine to the path on the remote machine:

    Path mapping
  4. Inspect the Update your script instructions. You can use the pydevd-pycharm.egg from the PyCharm installation (<PyCharm directory>/debug-egg/pydevd-pycharm.egg) or install the package using pip.

    Depending on your choice, perform the following changes:

    • Install the package on the remote machine by running the following command:

      for example,

    • Modify the source code file as follows:

    import math #==============this code added==================================================================: import pydevd_pycharm pydevd_pycharm.settrace('172.20.208.95', port=12345, stdoutToServer=True, stderrToServer=True) #================================================================================================ class Solver: def demo(self, a, b, c): d = b ** 2 - 4 * a * c if d > 0: disc = math.sqrt(d) root1 = (-b + disc) / (2 * a) root2 = (-b - disc) / (2 * a) return root1, root2 elif d == 0: return -b / (2 * a) else: return "This equation has no roots" if __name__ == '__main__': solver = Solver() while True: a = int(input("a: ")) b = int(input("b: ")) c = int(input("c: ")) result = solver.demo(a, b, c) print(result)

    Modify the code as follows:

    import math #==============this code added==================================================================: import sys sys.path.append("<PyCharm directory>/debug-egg/pydevd-pycharm.egg") import pydevd_pycharm pydevd_pycharm.settrace('172.20.208.95', port=12345, stdoutToServer=True, stderrToServer=True) #================================================================================================ class Solver: def demo(self, a, b, c): d = b ** 2 - 4 * a * c if d > 0: disc = math.sqrt(d) root1 = (-b + disc) / (2 * a) root2 = (-b - disc) / (2 * a) return root1, root2 elif d == 0: return -b / (2 * a) else: return "This equation has no roots" if __name__ == '__main__': solver = Solver() while True: a = int(input("a: ")) b = int(input("b: ")) c = int(input("c: ")) result = solver.demo(a, b, c) print(result)

Create a SFTP connection

  1. On the remote machine, create a directory where the file quadratic_equation.py should be uploaded. You can do it in the Terminal window:

    $cd /tmp $mkdir pycharm_project_986

  2. On the local machine, create a connection profile. From the main menu, choose . In the dialog that opens, click Add server, and in the Add Server dialog select the connection type (here SFTP) and enter its name (here MySFTPConnection).

  3. In the Connection tab, specify the SFTP host (address of the remote machine), username and password for that machine.

    Note that the specified user should have SSH access to the remote host.

  4. Click Mappings tab, and enter the deployment path in server. The server is , so click the browse button and select the required folder /tmp/pycharm_project_986. Note that the browse button shows the contents of the remote host. Apply changes and close the dialog.

Deploy files to the remote machine

  1. Deploy the following files to the remote machine: pydevd-pycharm.egg and quadratic_equation.py.

    On the local machine, in the Project tool window, select the files, right-click the selection and choose Deployment | Upload to MySFTPConnection.

  2. Inspect the File Transfer dialog window to ensure that the files from the local machine are uploaded to the remote server.

    File Transfer window

Launch the Debug Server

  1. Choose the created run/debug configuration, and click Debug:

    Running a debug configuration
  2. Ensure that the Debug tool window shows the Waiting for process connection.. message. This message will be shown until you launch your script on the remote machine, and this script will connect to the Debug Server.

Execute the Python file on the remote machine

  1. On the remote machine, navigate to the tmp/pycharm_project_986 directory.

  2. Launch the quadratic_equation.py file on the remote host. To do that, in the Terminal window, enter the following command:

    $python3 quadratic_equation.py

    $python quadratic_equation.py

    The most helpful aspect of this debugging method is that you can run execution the Python file using any of your bash scripts when remote debugging is part of a scheduled task or when you need to execute some preparation steps before running the Python script. If that's the case, add the following lines to the appropriate place of your bash script:

    cd /tmp/pycharm_project_986 python3 quadratic_equation.py

    cd /tmp/pycharm_project_986 python quadratic_equation.py

Debug your application

  • On your local machine, switch to the Debug tool window. It should show the connection to the pydev debugger.

    Remote debugging

    Your code is actually executed on the remote host, but debugged on the local machine.

Summary

In order to debug with a remote interpreter, you have to start your program through PyCharm, which is not always possible. On the other hand, when using the Debug Server, you can connect to a running process.

Compare the two approaches.

In the first case, we

In the second case, we

Last modified: 14 September 2021

Cython SpeedupsUsing Debug Console

Sours: https://www.jetbrains.com/help/pycharm/remote-debugging-with-product.html

Thonny

Mac OS X, Linux, Windows

For teaching/learning programming. Focused on program runtime visualization. Provides stepping both in statements and expressions, no-hassle variables view, separate mode for explaining references etc.

PyDev

Mac OS X, Linux, Windows

Allows debugging multiple threads in Jython and Python (It is featured as a 'Python IDE' plugin for Eclipse).

Wing IDE

Mac OS X, Linux, Windows

An IDE that can debug multiple threads and multiple processes, including code launched from the IDE or code launched externally, running under CPython and Stackless Python. The GUI includes a Debug Probe, which is a Python shell running in the context of the paused debug process. The IDE's debugger also features value watching (by symbolic path, object reference, or a combination), conditional breakpoints, move program counter, debugging of tests running in the integrated unit testing tool, special support for Django, and How-Tos for debugging code running under Flask, web3py, Django, Google App Engine, wxPython, PyQt, Tkinter, Blender, Maya, NUKE, and many other packages.

Komodo IDE

Mac OS X, Linux, Windows

!PyCharm IDE

Mac OS X, Linux, Windows

PyCharm's integrated debugger works for Python and Jython, supports debugging of multiple threads, remote debugging, allows debugging Django, Google App Engine applications and unit tests. The debugger features various breakpoints, stepping modes, frames view, watches, evaluate expression tool and a debug console. Conditional and Exception breakpoint types are available for more precise control. Debug console allows executing any Python statements in the context of the process being debugged while stopped at a breakpoint.

PyScripter

Windows

Pyshield

Linux, Windows

An IDE tool used to edit, debug Python scripts, publish encrypted scripts, build a standalone executable file, and make installation in various forms(.msi, .tar.gz, .rpm, .zip, .tar.bz2). It includes an editor simulating Emacs python-mode, a GUI debugger simulating GDB, a project view used to manage scripts, modules, extensions, packages and platform specific data files.

Python Tools for Visual Studio

Windows

Supports Python (any implementation with sufficient sys.settrace capabilities) and IronPython .NET debugging. Includes MPI cluster debugging, breakpoints, conditional breakpoints, locals, watch, and immediate windows, step into/out/over, break on exception, and break on unhandled exception.

Visual Studio Code

Mac OS X, Linux, Windows

Visual Studio Code is a source code editor developed by Microsoft for Windows, Linux and MacOS. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. It is free and open-source, although the official download is under a proprietary license. Supports Python debugging via extensions.

Mu

Mac OS X, Linux, Windows

A simple Python editor for beginner programmers, providing a simple interface depending on the project type. It includes visual debugging as first citizen.

Jupyter

Web (Mac OS X, Linux, Windows)

Web UI for Notebooks in Python and other programming language, has a visual debugger intregrated.

Sours: https://wiki.python.org/moin/PythonDebuggingTools
  1. Eus guided biliary drainage
  2. Inmate reception center cashier
  3. Pyramid super blue amp
  4. Socket5 proxy list

Remotely debug Python code on Linux

Visual Studio can launch and debug Python applications locally and remotely on a Windows computer (see Remote debugging). It can also debug remotely on a different operating system, device, or Python implementation other than CPython using the ptvsd library.

When using ptvsd, the Python code being debugged hosts the debug server to which Visual Studio can attach. This hosting requires a small modification to your code to import and enable the server, and may require network or firewall configurations on the remote computer to allow TCP connections.

movie camera icon for video For an introduction to remote debugging, see Deep Dive: Cross-platform remote debugging (youtube.com, 6m22s), which is applicable to both Visual Studio 2015 and 2017.

Set up a Linux computer

The following items are needed to follow this walkthrough:

  • A remote computer running Python on an operating system like Mac OSX or Linux.
  • Port 5678 (inbound) opened on that computer's firewall, which is the default for remote debugging.

You can easily create a Linux virtual machine on Azure and access it using Remote Desktop from Windows. Ubuntu for the VM is convenient because Python is installed by default; otherwise, see the list on Install a Python interpreter of your choice for additional Python download locations.

For details on creating a firewall rule for an Azure VM, see Open ports to a VM in Azure using the Azure portal.

Prepare the script for debugging

  1. On the remote computer, create a Python file called guessing-game.py with the following code:

  2. Install the package into your environment using .

    Note

    It's a good idea to record the version of ptvsd that's installed in case you need it for troubleshooting; the ptvsd listing also shows available versions.

  3. Enable remote debugging by adding the code below at the earliest possible point in guessing-game.py, before other code. (Though not a strict requirement, it's impossible to debug any background threads spawned before the function is called.)

  4. Save the file and run . The call to runs in the background and waits for incoming connections as you otherwise interact with the program. If desired, the function can be called after to block the program until the debugger attaches.

Tip

In addition to and , ptvsd also provides a helper function , which serves as a programmatic breakpoint if the debugger is attached. There is also an function that returns if the debugger is attached (note that there is no need to check this result before calling any other functions).

Attach remotely from Python Tools

In these steps, we set a simple breakpoint to stop the remote process.

  1. Create a copy of the remote file on the local computer and open it in Visual Studio. It doesn't matter where the file is located, but its name should match the name of the script on the remote computer.

  2. (Optional) To have IntelliSense for ptvsd on your local computer, install the ptvsd package into your Python environment.

  3. Select Debug > Attach to Process.

  4. In the Attach to Process dialog that appears, set Connection Type to Python remote (ptvsd). (On older versions of Visual Studio these commands are named Transport and Python remote debugging.)

  5. In the Connection Target field (Qualifier on older versions), enter where is that of the remote computer (which can be either an explicit address or a name like myvm.cloudapp.net), and is the remote debugging port number.

  6. Press Enter to populate the list of available ptvsd processes on that computer:

    Entering the connection target and listing processes

    If you happen to start another program on the remote computer after populating this list, select the Refresh button.

  7. Select the process to debug and then Attach, or double-click the process.

  8. Visual Studio then switches into debugging mode while the script continues to run on the remote computer, providing all the usual debugging capabilities. For example, set a breakpoint on the line, then switch over to the remote computer and enter another guess. After you do so, Visual Studio on your local computer stops at that breakpoint, shows local variables, and so on:

    Visual Studio pauses debugging when breakpoint is hit

  9. When you stop debugging, Visual Studio detaches from the program, which continues to run on the remote computer. ptvsd also continues listening for attaching debuggers, so you can reattach to the process again at any time.

Connection troubleshooting

  1. Make sure that you've selected Python remote (ptvsd) for the Connection Type (Python remote debugging for Transport with older versions.)

  2. Check that the secret in the Connection Target (or Qualifier) exactly matches the secret in the remote code.

  3. Check that the IP address in the Connection Target (or Qualifier) matches that of the remote computer.

  4. Check that you're opened the remote debugging port on the remote computer, and that you've included the port suffix in the connection target, such as .

    • If you need to use a different port, you can specify it in the call using the argument, as in . In this case, open that specific port in the firewall.
  5. Check that the version of ptvsd installed on the remote computer as returned by matches that used by the version of the Python tools you're using in Visual Studio in the table below. If necessary, update ptvsd on the remote computer.

    Visual Studio versionPython tools/ptvsd version
    2017 15.84.1.1a9 (legacy debugger: 3.2.1.0)
    2017 15.74.1.1a1 (legacy debugger: 3.2.1.0)
    2017 15.4, 15.5, 15.63.2.1.0
    2017 15.33.2.0
    2017 15.23.1.0
    2017 15.0, 15.13.0.0
    20152.2.6
    20132.2.2
    2012, 20102.1

Using ptvsd 3.x

The following information applies only to remote debugging with ptvsd 3.x, which contains certain features that were removed in ptvsd 4.x.

  1. With ptvsd 3.x, the function required that you pass a "secret" as the first argument that restricts access to the running script. You enter this secret when attaching the remote debugger. Though not recommended, you can allow anyone to connect, use .

  2. The connection target URL is where is the string passed in the Python code.

By default, the connection to the ptvsd 3.x remote debug server is secured only by the secret and all data is passed in plain text. For a more secure connection, ptvsd 3.x supports SSL using the protocol, which you set up as follows:

  1. On the remote computer, generate separate self-signed certificate and key files using openssl:

    When prompted, use the hostname or IP address (whichever you use to connect) for the Common Name when prompted by openssl.

    (See Self-signed certificates in the Python module docs for additional details. Note that the command in those docs generates only a single combined file.)

  2. In the code, modify the call to to include and arguments using the filenames as the values (these arguments have the same meaning as for the standard Python function):

    You can also make the same change in the code file on the local computer, but because this code isn't actually run, it isn't strictly necessary.

  3. Restart the Python program on the remote computer, making it ready for debugging.

  4. Secure the channel by adding the certificate to Trusted Root CA on the Windows computer with Visual Studio:

    1. Copy the certificate file from the remote computer to the local computer.
    2. Open Control Panel and navigate to Administrative Tools > Manage computer certificates.
    3. In the window that appears, expand Trusted Root Certification Authorities on the left side, right-click Certificates, and select All Tasks > Import.
    4. Navigate to and select the .cer file copied from the remote computer, then click through the dialogs to complete the import.
  5. Repeat the attach process in Visual Studio as described earlier, now using as the protocol for the Connection Target (or Qualifier).

    Choosing the remote debugging transport with SSL

  6. Visual Studio prompts you about potential certificate issues when connecting over SSL. You may ignore the warnings and proceed, but although the channel is still encrypted against eavesdropping it can be open to man-in-the-middle attacks.

    1. If you see the remote certificate is not trusted warning below, it means you did not properly add the certificate to the Trusted Root CA. Check those steps and try again.

      SSL certificate trusted warning

    2. If you see the remote certificate name does not match hostname warning below, it means you did not use the proper hostname or IP address as the Common Name when creating the certificate.

      SSL certificate hostname warning

Visual Studio can launch and debug Python applications locally and remotely on a Windows computer (see Remote debugging). It can also debug remotely on a different operating system, device, or Python implementation other than CPython using the debugpy library.

When using debugpy, the Python code being debugged hosts the debug server to which Visual Studio can attach. This hosting requires a small modification to your code to import and enable the server, and may require network or firewall configurations on the remote computer to allow TCP connections.

Note

For Visual Studio 2019 version 16.4 and earlier, the ptvsd library was used. The debugpy library replaced ptvsd 4 in Visual Studio 2019 version 16.5.

Set up a Linux computer

The following items are needed to follow this walkthrough:

  • A remote computer running Python on an operating system like Mac OSX or Linux.
  • Port 5678 (inbound) opened on that computer's firewall, which is the default for remote debugging.

Note

This walkthrough is based on Visual Studio 2019 version 16.6.

You can easily create a Linux virtual machine on Azure and access it using Remote Desktop from Windows. Ubuntu for the VM is convenient because Python is installed by default; otherwise, see the list on Install a Python interpreter of your choice for additional Python download locations.

For details on creating a firewall rule for an Azure VM, see Open ports to a VM in Azure using the Azure portal.

Prepare the script for debugging

  1. On the remote computer, create a Python file called guessing-game.py with the following code:

  2. Install the package into your environment using .

    Note

    It's a good idea to record the version of debugpy that's installed in case you need it for troubleshooting; the debugpy listing also shows available versions.

  3. Enable remote debugging by adding the code below at the earliest possible point in guessing-game.py, before other code. (Though not a strict requirement, it's impossible to debug any background threads spawned before the function is called.)

  4. Save the file and run . The call to runs in the background and waits for incoming connections as you otherwise interact with the program. If desired, the function can be called after to block the program until the debugger attaches.

Tip

In addition to and , debugpy also provides a helper function , which serves as a programmatic breakpoint if the debugger is attached. There is also an function that returns if the debugger is attached (note that there is no need to check this result before calling any other functions).

Attach remotely from Python Tools

In these steps, we set a simple breakpoint to stop the remote process.

  1. Create a copy of the remote file on the local computer and open it in Visual Studio. It doesn't matter where the file is located, but its name should match the name of the script on the remote computer.

  2. (Optional) To have IntelliSense for debugpy on your local computer, install the debugpy package into your Python environment.

  3. Select Debug > Attach to Process.

  4. In the Attach to Process dialog that appears, set Connection Type to Python remote (debugpy).

  5. In the Connection Target field, enter where is that of the remote computer (which can be either an explicit address or a name like myvm.cloudapp.net), and is the remote debugging port number.

  6. Press Enter to populate the list of available debugpy processes on that computer:

    Entering the connection target and listing processes

    If you happen to start another program on the remote computer after populating this list, select the Refresh button.

  7. Select the process to debug and then Attach, or double-click the process.

  8. Visual Studio then switches into debugging mode while the script continues to run on the remote computer, providing all the usual debugging capabilities. For example, set a breakpoint on the line, then switch over to the remote computer and enter another guess. After you do so, Visual Studio on your local computer stops at that breakpoint, shows local variables, and so on:

    Visual Studio pauses debugging when breakpoint is hit

  9. When you stop debugging, Visual Studio detaches from the program, which continues to run on the remote computer. debugpy also continues listening for attaching debuggers, so you can reattach to the process again at any time.

Connection troubleshooting

  1. Make sure that you've selected Python remote (debugpy) for the Connection Type

  2. Check that the secret in the Connection Target exactly matches the secret in the remote code.

  3. Check that the IP address in the Connection Target matches that of the remote computer.

  4. Check that you've opened the remote debugging port on the remote computer, and that you've included the port suffix in the connection target, such as .

    • If you need to use a different port, you can specify it in the , as in . In this case, open that specific port in the firewall.
  5. Check that the version of debugpy installed on the remote computer as returned by matches that used by the version of the Python tools you're using in Visual Studio in the table below. If necessary, update debugpy on the remote computer.

    Visual Studio versionPython tools/debugpy version
    2019 16.61.0.0b5
    2019 16.51.0.0b1

Note

Visual Studio 2019 version 16.0-16.4 utilized ptvsd, not debugpy. The process in this walkthrough for those versions is similar, but the function names are different. Visual Studio 2019 version 16.5 uses debugpy, but the function names were the same as those in ptvsd. Instead of , you would use . Instead of , you would use . Instead of , you would use .

Using ptvsd 3.x for legacy debugging

Visual Studio 2017 versions 15.8 and later use a debugger based on ptvsd version 4.1+. Visual Studio 2019 versions 16.5 and later use a debugger based on debugpy. These versions of the debugger are compatible with Python 2.7 and Python 3.5+. If you're using Python 2.6, 3.1 to 3.4, or IronPython, Visual Studio shows the error, Debugger does not support this Python environment. The following information applies only to remote debugging with ptvsd 3.x.

  1. With ptvsd 3.x, the function required that you pass a "secret" as the first argument that restricts access to the running script. You enter this secret when attaching the remote debugger. Though not recommended, you can allow anyone to connect, use .

  2. The connection target URL is where is the string passed in the Python code.

By default, the connection to the ptvsd 3.x remote debug server is secured only by the secret and all data is passed in plain text. For a more secure connection, ptvsd 3.x supports SSL using the protocol, which you set up as follows:

  1. On the remote computer, generate separate self-signed certificate and key files using openssl:

    When prompted, use the hostname or IP address (whichever you use to connect) for the Common Name when prompted by openssl.

    (See Self-signed certificates in the Python module docs for additional details. Note that the command in those docs generates only a single combined file.)

  2. In the code, modify the call to to include and arguments using the filenames as the values (these arguments have the same meaning as for the standard Python function):

    You can also make the same change in the code file on the local computer, but because this code isn't actually run, it isn't strictly necessary.

  3. Restart the Python program on the remote computer, making it ready for debugging.

  4. Secure the channel by adding the certificate to Trusted Root CA on the Windows computer with Visual Studio:

    1. Copy the certificate file from the remote computer to the local computer.
    2. Open Control Panel and navigate to Administrative Tools > Manage computer certificates.
    3. In the window that appears, expand Trusted Root Certification Authorities on the left side, right-click Certificates, and select All Tasks > Import.
    4. Navigate to and select the .cer file copied from the remote computer, then click through the dialogs to complete the import.
  5. Repeat the attach process in Visual Studio as described earlier, now using as the protocol for the Connection Target (or Qualifier).

    Choosing the remote debugging transport with SSL

  6. Visual Studio prompts you about potential certificate issues when connecting over SSL. You may ignore the warnings and proceed, but although the channel is still encrypted against eavesdropping it can be open to man-in-the-middle attacks.

    1. If you see the remote certificate is not trusted warning below, it means you did not properly add the certificate to the Trusted Root CA. Check those steps and try again.

      SSL certificate trusted warning

    2. If you see the remote certificate name does not match hostname warning below, it means you did not use the proper hostname or IP address as the Common Name when creating the certificate.

      SSL certificate hostname warning

Feedback

View all page feedback

Sours: https://docs.microsoft.com/en-us/visualstudio/python/debugging-python-code-on-remote-linux-machines

Remote Debugging Guide for Python

Ever have a tough bug in production that doesn't show up on your machine even after having parity with pretty much everything? Or perhaps you don't have much of a choice, but to work directly on the server? Do you end up using print or a logger and just haphazardly plopping those in in different places hoping to see what's going on?

I'll present to you remote debugging. Remote debugging allows you to interactively debug code that's not on your machine line-by-line. It's as others have described a "God-send" into debugging tough problems. You'll get to the root of the problem much quicker with it and it's extremely useful when you need to reverse-engineer a project.

We'll be using a python package to have a common API to work with.

  • Visual Studio Code or Pycharm Professional
  • Either ptvsd or pydevd_pycharm dependency installed

There's five parts to remote debugging with Python:

  1. the server can communicate with your workstation
  2. you have the corresponding IDE package installed on the server
  3. your IDE is configured for remote debugging correctly
  4. you run the remote debugging configuration in your IDE at the right
    time
  5. you have the same code that's on the server on your workstation

debugger-diagram.png

There's a debug package for each IDE that serves as the debugger on the
server. It communicates back and forth between the server and the IDE.

You need to make sure that the server can communicate with your
workstation. This is an essential part of remote debugging because
there are TCP packets sent back and forth between the server and the
IDE. Those packets communicate things like where the breakpoints are set
and information about the current stack and variables. This is
essentially how all remote debuggers work.

The easiest way to allow a TCP line-of-communication that bypasses any
firewall issues is by port forwarding. This is possible with ssh or
putty.

With ssh just issue for a
reverse port forward and
for a local port forward. Typically you'd use for the IP and
the same port numbers, for example,
. A local port forward means that
a socket is allocated and listening on your local machine and forwards
the TCP connection to the specified remote port on the server. A reverse
port forward means that a socket is allocated and listening on your
remote machine and forwards the TCP connection to the specified local
port on your machine. Visual Studio Code uses local port forwarding
while PyCharm needs reverse port forwarding.

To ensure that the server can communicate with your computer you could
run the following commands on the server:

If you have telnet installed you could also try...

What you're looking for is for openssl. For telnet, if it
doesn't exit telnet and doesn't get an error after some time, then that
means it's connected.

In terms of the setup, that means that for PyCharm you need to run the
remote IDE configuration first before running your python script while
for Visual Studio Code you run it after your python script.

The remote debugger IDE settings define the host, port, and path
mappings. The path mapping maps the folder path from the server to the
folder path on your local machine so that the debugger can pick up the
correct file.

There are three environment variables that the debugger_helper module
uses:

  • (default )
  • (default )

The environment variable should be set to any non-empty
value such as right before starting the python script you'd like to
debug.

If everything is set up correctly the debugger should immediately stop
at your breakpoint. If this is not the case, double check every step.

  • install on the server
  • make sure isn't installed as it conflicts with
  • add a local port forward from your machine to the server via ssh (or
    putty)
  • add the following to somewhere in the top-most part of your python
    project. For instance, if it's a Flask app with an app.py file you
    might place it right at the top after your imports.
  • go to the debug panel, add configuration, click on Python, then
    Remote Attach, set the host to , port to (or the
    port to match the port forwarding and the
    environment variable). You should see those values in .
  • for , set it to the absolute path of the folder
    containing your python script on the server. For instance, maybe
    it's residing in . You'd use that for .
  • set a breakpoint where you'd like the debugger to stop
  • Run the python script and waiting
    until it says it's ready to connect to the debugger
  • Run the Remote Attach configuration in Visual Studio Code.
  • install on the server
  • add a reverse port forward from the server to your machine via ssh
    (or putty)
  • add a Run Configuration for Python Remote Debug. Set the host to
    and port . Save it.
  • in the configuration and path mapping field add a mapping for the
    absolute path of the project root to the absolute path of the same
    project root, but on the server
  • add the following to somewhere in the top-most part of your python
    project. For instance, if it's a Flask app with an app.py file you
    might place it right at the top after your imports.
  • set a breakpoint where you'd like the debugger to stop. You may set
    if you'd like to avoid
    the debugger from stopping on the line that is on.
  • Run the Remote Debug configuration in PyCharm.
  • Run the python script

One of the challenges with remote debugging is that by default if you make code changes, they will not be reflected immediately on the server. If you're not aware of that you'll be debugging an older version of your code and seeing results that don't correlate to the changes that you made.

What you need to do is to restart the python process when a python file is updated. We can do this automatically with .

So lets go through that.

  • install
  • create a second script that will call your main python script that turns on the debugger. It should look something like this:
  • Run the python script with watchgod
  • Now in your IDE, upload the file

Maybe you want to turn on the debugger only when you'd like to?

Here's an example of how to do that in Flask. Unfortunately, the IDE packages don't allow disabling the debugger once it's been turned on so we're going to have to brute-force it by killing the python process. That means that you'll need to manually start it again or you could use something like gunicorn that'll spawn a new process after it sees that the old process gets killed.

Follow along with me.

  • create a function that'll check a query parameter and then trigger
    the debugger to start
  • notice the argument in .
    That allows you to trigger the debugger based on your set of rules.
  • call this function in the body of the route

Now that you've learned how to do remote debugging, go ahead and get your hands dirty. Once you've used it, you'll be asking yourself why you didn't use it earlier.

Happy debugging!

Sours: https://www.codementor.io/@jorgecolon/remote-debugging-in-python-v1cbnej91

Debugging python remote

Remote Debugger

In PyDev you can debug a remote program (a file that is not launched from within Eclipse).

The steps to debug an external program are:

  • 1. Start the remote debugger server
  • 2. Go to the debug perspective
  • 3. Start the external program with the file pydevd.py in its PYTHONPATH
  • 4. Call pydevd.settrace()
    • Note: if the program is being edited inside of PyDev (and launched externally), you can write only pydevd and request a code-completion which will add pydevd.py to sys.path and do the settrace (i.e.: steps 3 and 4).

Let's see a simple step-by-step example on how this works:

1. Start the remote debugger server: To start the remote debugger server, go to the menu: PyDev > Start Debug Server. When running, a Debug Server entry should appear in the Debug Stack view.

Note: That menu item should be present at the debug perspective and it can be enabled in other perspectives through Window > Perspective > Customize perspective > Tool Bar Visibility > PyDev debug.

Image: Remote Debugger Server

2. Go to the debug perspective: This is needed because it has no actual 'signal' that it reached a breakpoint when doing remote debugging. So, if you already have it open, just cycle to it with Ctrl+F8. Otherwise, go to the menu: window > Open Perspective > Other > Debug.

3. Call pydevd.settrace(). If the program is being edited inside of PyDev (and launched externally), you can write only pydevd and request a code-completion which will add pydevd.py to sys.path and do the pydevd.settrace().

Now, if you're launching from a different computer, you should copy the contents of PyDev.Debugger to the target computer. If you're in the latest version, it may be installed with pip install pydevd. Otherwise, you have to copy the pysrc contents of org.python.pydev plugin from your Eclipse installation.

Note: if the target machine does not have the same paths as the client machine, the file pydevd_file_utils.py must be edited to properly translate the paths from one machine to the other - see comments on that file.

4. Launch the program and wait for it to reach the pydevd.settrace() call: When that call is reached, it will automatically suspend the execution and show the debugger.

Image: pydevd.settrace called

NOTE 1: the settrace() function can have an optional parameter to specify the host where the remote debugger is listening. E.g.: pydevd.settrace('10.0.0.1')

NOTE 2: the settrace() function can have optional parameters to specify that all the messages printed to stdout or stderr should be passed to the server to show. E.g.: pydevd.settrace(stdoutToServer=True, stderrToServer=True)

NOTE 3: You can have the running program in one machine and PyDev on another machine, but if the paths are not exactly the same, some adjustments have to be done in the target machine:

Aside from passing the files in eclipse/plugins/org.python.pydev_x.x.x/pysrc to your target machine, the file pydevd_file_utils.py must be edited to make the path translations from the client machine to the server machine and vice-versa. See the comments on that file for detailed instructions on setting the path translations.





Sours: https://www.pydev.org/manual_adv_remote_debugger.html
How to do remote debugging using VS Code

Python debugging in VS Code

The Python extension supports debugging of several types of Python applications. For a short walkthrough of basic debugging, see Tutorial - Configure and run the debugger. Also see the Flask tutorial. Both tutorials demonstrate core skills like setting breakpoints and stepping through code.

For general debugging features such as inspecting variables, setting breakpoints, and other activities that aren't language-dependent, review VS Code debugging.

This article addresses only those considerations that are specific to Python, mainly Python-specific debugging configurations, including the necessary steps for specific app types and remote debugging.

Initialize configurations

A configuration drives VS Code's behavior during a debugging session. Configurations are defined in a file that's stored in a folder in your workspace.

Note To change debugging configuration, your code must be stored in a folder.

To initialize debug configurations, first select the Run view in the sidebar:

Run icon

If you don't yet have any configurations defined, you'll see a button to Run and Debug, as well as a link to create a configuration (launch.json) file:

Debug toolbar settings command

To generate a file with Python configurations, do the following steps:

  1. Click the create a launch.json file link (circled in the image above) or use the Run > Open configurations menu command.

  2. A configuration menu will open from the Command Palette allowing you to choose the type of debug configuration you want for the opened file. For now, in the Select a debug configuration menu that appears, select Python File. Debug configurations menu

    Note Starting a debugging session through the Debug Panel, F5 or Run > Start Debugging when no configuration exists will also bring up the debug configuration menu, but will not create a launch.json file.

  3. The Python extension then creates and opens a file that contains a pre-defined configuration based on what you previously selected, in this case, Python File. You can modify configurations (to add arguments, for example), and also add custom configurations.

    Configuration json

The details of configuration properties are covered later in this article under Standard configuration and options. Additional configurations are also described in this article under Debugging specific app types.

Additional configurations

By default, VS Code shows only the most common configurations provided by the Python extension. You can select other configurations to include in by using the Add Configuration command shown in the list and the editor. When you use the command, VS Code prompts you with a list of all available configurations (be sure to scroll down to see all the Python options):

Adding a new Python debugging configuration

Selecting the Node.js: Gulp task yields the following result: Added a configuration

See Debugging specific app types for details on all of these configurations.

During debugging, the Status Bar shows the current configuration and the current debugging interpreter. Selecting the configuration brings up a list from which you can choose a different configuration:

Debugging Status Bar

By default, the debugger uses the same interpreter selected for your workspace, just like other features of Python extension for VS Code. To use a different interpreter for debugging specifically, set the value for in for the applicable debugger configuration. Alternately, select the named interpreter on the Status Bar to select a different one.

Basic debugging

If you're only interested in debugging a Python script, the simplest way is to click on the down-arrow next to the run button on the editor and select Debug Python File in Terminal.

Debug button on the top-right of the editor

But if you're looking to debug a module or a web application for example, you can start the debugger through the Run view by clicking on the Run and Debug button.

Run the debugger

When no configuration has been previously set, you will be presented with a list of debugging options. Select the appropriate option to quickly begin debugging your code.

Two common options are to use the Python File configuration to run the currently open Python file or to use the Attach using Process ID configuration to attach the debugger to a process that is already running.

For information about creating and using debugging configurations see the Initialize configurations and Additional configurations sections. Once a configuration is added, it can be selected from the dropdown list and started using the Start Debugging button.

Start debugging

Command line debugging

The debugger can also be run from the command line. The debugger command line syntax is as follows:

As an example, from the command line, you could start the debugger using a specified port (5678) and script using the following syntax. This example assumes the script is long-running and omits the flag, meaning that the script will not wait for the client to attach.

You would then use the following configuration to attach from the VS Code Python extension.

Note: Specifying host is optional for listen, by default 127.0.0.1 is used.

If you wanted to debug remote code or code running in a docker container, on the remote machine or container, you would need to modify the previous CLI command to specify a host.

The associated configuration file would then look as follows.

Note: Be aware that when you specify a host value other than or you are opening a port to allow access from any machine, which carries security risks. You should make sure that you're taking appropriate security precautions, such as using SSH tunnels, when doing remote debugging.

FlagOptionsDescription
--listen or --connectRequired. Specifies the host address and port for the debug adapter server to wait for incoming connections (--listen) or to connect with a client that is waiting for an incoming connection (--connect). This is the same address that is used in the VS Code debug configuration. By default, the host address is .
--wait-for-clientnoneOptional. Specifies that the code should not run until there's a connection from the debug server. This setting allows you to debug from the first line of your code.
--log-toOptional. Specifies a path to an existing directory for saving logs.
--log-to-stderrnoneOptional. Enables debugpy to write logs directly to stderr.
--pidOptional. Specifies a process that is already running to inject the debug server into.
--configure-<name>Optional. Sets a debug property that must be known to the debug server before the client connects. Such properties can be used directly in launch configuration, but must be set in this manner for attach configurations. For example, if you don't want the debug server to automatically inject itself into subprocesses created by the process you're attaching to, use .

Note: can be used to pass command-line arguments along to the app being launched.

Debugging by attaching over a network connection

Local script debugging

In some scenarios, you need to debug a Python script that's invoked locally by another process. For example, you may be debugging a web server that runs different Python scripts for specific processing jobs. In such cases, you need to attach the VS Code debugger to the script once it's been launched:

  1. Run VS Code, open the folder or workspace containing the script, and create a for that workspace if one doesn't exist already.

  2. In the script code, add the following and save the file:

  3. Open a terminal using Terminal: Create New Terminal, which activates the script's selected environment.

  4. In the terminal, install the debugpy package with .

  5. In the terminal, start Python with the script, for example, . You should see the "Waiting for debugger attach" message that's included in the code, and the script halts at the call.

  6. Switch to the Run view, select the appropriate configuration from the debugger dropdown list, and start the debugger.

  7. The debugger should stop on the call, from which point you can use the debugger normally. You can, of course, set other breakpoints in the script code using the UI instead of using .

Remote script debugging with SSH

Remote debugging allows you to step through a program locally within VS Code while it runs on a remote computer. It is not necessary to install VS Code on the remote computer. For added security, you may want or need to use a secure connection, such as SSH, to the remote computer when debugging.

Note: On Windows computers, you may need to install Windows 10 OpenSSH to have the command.

The following steps outline the general process to set up an SSH tunnel. An SSH tunnel allows you to work on your local machine as if you were working directly on the remote in a more secure manner than if a port was opened for public access.

On the remote computer:

  1. Enable port forwarding by opening the config file (found under on Linux and under on Windows) and adding or modifying the following setting:

    Note: The default for AllowTcpForwarding is yes, so you might not need to make a change.

  2. If you had to add or modify , restart the SSH server. On Linux/macOS, run ; on Windows, run , locate and select OpenSSH or in the list of services, and select Restart.

On the local computer:

  1. Create an SSH tunnel by running , using a selected port for and the appropriate username and the remote computer's IP address in . For example, to use port 5678 on IP address 1.2.3.4, the command would be . You can specify the path to an identity file, using the flag.

  2. Verify that you can see a prompt in the SSH session.

  3. In your VS Code workspace, create a configuration for remote debugging in your file, setting the port to match the port used in the command and the host to . You use here because you've set up the SSH tunnel.

Starting debugging

Now that an SSH tunnel has been set up to the remote computer, you can begin your debugging.

  1. Both computers: make sure that identical source code is available.

  2. Both computers: install debugpy using into your environment (while using a form of virtual environment is not required, it is a recommended best practice).

  3. Remote computer: there are two ways to specify how to attach to the remote process.

    1. In the source code, add the following lines, replacing with the remote computer's IP address and port number (IP address 1.2.3.4 is shown here for illustration only).

      The IP address used in should be the remote computer's private IP address. You can then launch the program normally, causing it to pause until the debugger attaches.

    2. Launch the remote process through debugpy, for example:

      This starts the package using , with the remote computer's private IP address of and listening on port (you can also start the remote Python process by specifying a file path instead of using , such as ).

  4. Local computer: Only if you modified the source code on the remote computer as outlined above, then in the source code, add a commented-out copy of the same code added on the remote computer. Adding these lines makes sure that the source code on both computers matches line by line.

  5. Local computer: switch to the Run view in VS Code, select the Python: Attach configuration

  6. Local computer: set a breakpoint in the code where you want to start debugging.

  7. Local computer: start the VS Code debugger using the modified Python: Attach configuration and the Start Debugging button. VS Code should stop on your locally set breakpoints, allowing you to step through the code, examine variables, and perform all other debugging actions. Expressions that you enter in the Debug Console are run on the remote computer as well.

    Text output to stdout, as from statements, appears on both computers. Other outputs, such as graphical plots from a package like matplotlib, however, appear only on the remote computer.

  8. During remote debugging, the debugging toolbar appears as below:

    Debugging toolbar during remote debugging

    On this toolbar, the disconnect button (⇧F5 (Windows, Linux Shift+F5)) stops the debugger and allows the remote program to run to completion. The restart button (⇧⌘F5 (Windows, Linux Ctrl+Shift+F5)) restarts the debugger on the local computer but does not restart the remote program. Use the restart button only when you've already restarted the remote program and need to reattach the debugger.

Set configuration options

When you first create , there are two standard configurations that run the active file in the editor in either the integrated terminal (inside VS Code) or the external terminal (outside of VS Code):

The specific settings are described in the following sections. You can also add other settings, such as , that aren't included in the standard configurations.

Tip: It's often helpful in a project to create a configuration that runs a specific startup file. For example, if you want to always launch with the arguments when you start the debugger, create a configuration entry as follows:

Provides the name for the debug configuration that appears in the VS Code dropdown list.

Identifies the type of debugger to use; leave this set to for Python code.

Specifies the mode in which to start debugging:

  • : start the debugger on the file specified in
  • : attach the debugger to an already running process. See Remote debugging for an example.

Provides the fully qualified path to the python program's entry module (startup file). The value , often used in default configurations, uses the currently active file in the editor. By specifying a specific startup file, you can always be sure of launching your program with the same entry point regardless of which files are open. For example:

You can also rely on a relative path from the workspace root. For example, if the root is then you can use the following:

Provides the ability to specify the name of a module to be debugged, similarly to the argument when run at the command line. For more information, see Python.org

The full path that points to the Python interpreter to be used for debugging.

If not specified, this setting defaults to the interpreter selected for your workspace, which is equivalent to using the value . To use a different interpreter, specify its path instead in the property of a debug configuration.

Alternately, you can use a custom environment variable that's defined on each platform to contain the full path to the Python interpreter to use, so that no additional folder paths are needed.

If you need to pass arguments to the Python interpreter, you can use the property.

Specifies arguments to pass to the Python interpreter using the syntax .

Specifies arguments to pass to the Python program. Each element of the argument string that's separated by a space should be contained within quotes, for example:

When set to , breaks the debugger at the first line of the program being debugged. If omitted (the default) or set to , the debugger runs the program to the first breakpoint.

Specifies how program output is displayed as long as the defaults for aren't modified.

ValueWhere output is displayed
VS Code debug console. If is set to False, no output is displayed.
(default)VS Code Integrated Terminal. If is set to True, output is also displayed in the debug console.
Separate console window. If is set to True, output is also displayed in the debug console.

If set to , defines that the configuration should be used when debugging tests in VS Code. If set to , defines that the configuration should be used when and only when using the Debug Python File in Terminal button on the top-right of the editor. Note that the option can't be used to start the debugger through F5 or Run > Start Debugging.

Allows for the automatic reload of the debugger when changes are made to code after the debugger execution has hit a breakpoint. To enable this feature set as shown in the following code.

*Note: When the debugger performs a reload, code that runs on import might be executed again. To avoid this situation, try to only use imports, constants, and definitions in your module, placing all code into functions. Alternatively, you can also use checks.

Specifies whether to enable subprocess debugging. Defaults to , set to to enable. For more information, see multi-target debugging.

Specifies the current working directory for the debugger, which is the base folder for any relative paths used in code. If omitted, defaults to (the folder open in VS Code).

As an example, say contains a folder containing , and a folder containing . If you start the debugger on , then the relative paths to the data file vary depending on the value of :

cwdRelative path to data file
Omitted or

When set to (the default for internalConsole), causes the debugger to print all output from the program into the VS Code debug output window. If set to (the default for integratedTerminal and externalTerminal), program output is not displayed in the debugger output window.

This option is typically disabled when using or because there's no need to duplicate the output in the debug console.

When omitted or set to (the default), restricts debugging to user-written code only. Set to to also enable debugging of standard library functions.

When set to , activates debugging features specific to the Django web framework.

When set to and used with , allows for debugging apps that require elevation. Using an external console is necessary to capture the password.

When set to , ensures that a Pyramid app is launched with the necessary command.

Sets optional environment variables for the debugger process beyond system environment variables, which the debugger always inherits. The values for these variables must be entered as strings.

Optional path to a file that contains environment variable definitions. See Configuring Python environments - environment variable definitions file.

If set to , enables debugging of gevent monkey-patched code.

Breakpoints and logpoints

The Python extension supports breakpoints and logpoints for debugging code. For a short walkthrough of basic debugging and using breakpoints, see Tutorial - Configure and run the debugger.

Conditional breakpoints

Breakpoints can also be set to trigger based on expressions, hit counts, or a combination of both. The Python extension support hit counts that are integers, as well as integers preceded by the ==, >, >=, <, <=, and % operators. For example, you could set a breakpoint to trigger after 5 occurrences by setting a hitcount of For more information, see conditional breakpoints in the main VS Code debugging article.

Invoking a breakpoint in code

In your Python code, you can call at any point where you want to pause the debugger during a debugging session.

Breakpoint validation

The Python extension automatically detects breakpoints that are set on non-executable lines, such as statements or the middle of a multiline statement. In such cases, running the debugger moves the breakpoint to the nearest valid line to ensure that code execution stops at that point.

Debugging specific app types

The configuration dropdown provides a variety of different options for general app types:

ConfigurationDescription
AttachSee Remote debugging in the previous section.
DjangoSpecifies , . Also adds to enable debugging of Django HTML templates.
FlaskSee Flask debugging below.
GeventAdds to the standard integrated terminal configuration.
PyramidRemoves , adds , adds for enabling template debugging, and adds to ensure that the program is launched with the necessary command.
ScrapySpecifies and adds .
WatsonSpecifies and .

Specific steps are also needed for remote debugging and Google App Engine. For details on debugging tests, see Testing.

To debug an app that requires administrator privileges, use and .

Flask debugging

As you can see, this configuration specifies and . The property is used instead of . (You may see in the property, in which case modify the configuration to refer to only the filename. Otherwise, you may see "Cannot import module C" errors where C is a drive letter.)

The setting also enables debugging for Flask's default Jinja templating engine.

If you want to run Flask's development server in development mode, use the following configuration:

Troubleshooting

There are many reasons why the debugger may not work. Oftentimes the debug console reveals specific causes, but two specific reasons are as follows:

  • The path to the python executable is incorrect: check the path of your selected interpreter by running the Python: Select Interpreter command and looking at the current value:

    Troubleshooting wrong Python interpreter when debugging

  • There are invalid expressions in the watch window: clear all expressions from the Watch window and restart the debugger.

  • If you're working with a multi-threaded app that uses native thread APIs (such as the Win32 function rather than the Python threading APIs), it's presently necessary to include the following source code at the top of whichever file you want to debug:

Next steps

  • Python environments - Control which Python interpreter is used for editing and debugging.
  • Testing - Configure test environments and discover, run, and debug tests.
  • Settings reference - Explore the full range of Python-related settings in VS Code.
  • General debugging - Learn about the debugging features of VS Code.

9/1/2021

Sours: https://code.visualstudio.com/docs/python/debugging

Now discussing:

Remote vanilla PDB (over TCP sockets) done right: no extras, proper handling around connection failures and CI. Based on pdbx.

  • Free software: BSD 2-Clause License

Installation

pip install remote-pdb

Usage

To open a remote PDB on first available port:

fromremote_pdbimportset_traceset_trace()# you'll see the port number in the logs

To use some specific host/port:

fromremote_pdbimportRemotePdbRemotePdb('127.0.0.1',4444).set_trace()

To connect just run . When you are finished debugging, either exit the debugger, or press Control-], then Control-d.

Alternately, one can connect with NetCat: or Socat: (for line editing and history support). When finished debugging, either exit the debugger, or press Control-c.

Note that newer Ubuntu disabled readline support in socat, so if you get try using rlwrap like this:

rlwrap socat - tcp:127.0.0.1:4444

Using in containers

If you want to connect from the host to remote-pdb running inside the container you should make sure that:

  • The port you will use is mapped (eg: ).
  • The host is set to ( will not work because Docker doesn’t map the port on the local interface).

Integration with breakpoint() in Python 3.7+

If you are using Python 3.7 one can use the new built in to invoke remote PDB. In this case the following environment variable must be set:

PYTHONBREAKPOINT=remote_pdb.set_trace

The debugger can then be invoked as follows, without any imports:

breakpoint()

As the function does not take any arguments, environment variables can be used to specify the host and port that the server should listen to. For example, to run in such a way as to make the correct way of connecting, one would run:

PYTHONBREAKPOINT=remote_pdb.set_trace REMOTE_PDB_HOST=127.0.0.1 REMOTE_PDB_PORT=4444 python script.py

If is omitted then a default value of 127.0.0.1 will be used. If is omitted then the first available port will be used. The connection information will be logged to the console, as with calls to .

To quiet the output, set , this will prevent from producing any output – you’ll probably want to specify as well since the randomized port won’t be printed.

Note about OS X

In certain scenarios (backgrounded processes) OS X will prevent readline to be imported (and readline is a dependency of pdb). A workaround (run this early):

importsignalsignal.signal(signal.SIGTTOU,signal.SIG_IGN)

See #9 and cpython#14892.

Requirements

Python 2.6, 2.7, 3.2, 3.3 and PyPy are supported.

Changelog

2.1.0 (2020-07-24)

  • Changed logging to use logger instead of the root one. Contributed by Terence Honles in #24.

2.0.0 (2019-07-31)

  • Fixed inconsistency with normal use of - BdbQuit will now be raised on quitting. Contributed by Anthony Sottile in #18. BACKWARDS INCOMPATIBLE.
  • Added to silence output. Contributed by Anthony Sottile in #19.

1.3.0 (2019-03-13)

  • Documented support for Python 3.7’s .
  • Added support for setting the socket listening host/port through the / environment variables. Contributed by Matthew Wilkes in #14.
  • Removed use of rw file wrappers around sockets (turns out socket’s is very buggy in Python 3.6 and later - output is discarded). Contributed in #13.

1.2.0 (2015-09-26)

  • Always print/log listening address.

1.1.3 (2015-07-06)

  • Corrected the default frame tracing starts from.

1.1.1 (2015-07-06)

  • Remove bogus console script.

1.1.0 (2015-06-21)

  • Fixed buffering issues when running on Python 3 and Windows.
Sours: https://pypi.org/project/remote-pdb/


21611 21612 21613 21614 21615