Bring back Python 3.6 debugging support by breaking debugging out into its own extension

[brettcannon]

By making debugging a separate extension we can do an initial release using debugpy 1.5 which will work all the way back to Python 2.7, and then immediately do another release using debugpy 1.6. That way people who need debugging support for older Python versions can pin the debugging extension version but leave the Python extension alone to get newer feature support (if it works with the old version of Python that they are running).

[aamarin]

Is this only for debugging support? Or can Intellisense also be included? I work for a company that uses Red Hat 7 which does support 3.6 as part of the distribution.

[brettcannon]

This is only explicitly for debugging as IntelliSense shouldn't be affected by any of this as Pylance is written in TypeScript. If you're using Jedi then that is up to the Jedi project itself in terms of what versions they support.

[nutu]

I am feeling that this answers my question on why my debugger does not start: https://stackoverflow.com/questions/74812777/vs-code-python-debugger-would-not-start-with-python-extension-2022-xx-xx-althoug?noredirect=1#comment132043707_74812777
What is the minimal python version that still works with the python extension debugger?

[brettcannon]

What is the minimal python version that still works with the python extension debugger?

Python 3.7.

[yanjieee]

v2022.6.3 working fine

[GitMensch]

Is there any ETA? I'm regularly hit by the update / new install then later wonder why something doesn't work on a remote...
Additional this would make the Python extension itself smaller which is nice for people that don't actually need to debug.

... and wouldn't this issue be still the same, so Python 2.7 still won't work (last time it did was v2022.2.x, I think)?

IntelliSense with Jedi for Python 2.7 is no longer supported

[brettcannon]

@GitMensch no promises, but we are hoping for a preview release in May.

And Python 2.7 is in the same situation as 3.6, so we would have to see if the last debugpy release would work with the extension and then make that the initial release, do an immediate new release for one that uses the newest version that supports back to Python 3.6, and then do yet another immediate release that uses the newest version of debugpy regardless of Python version support. But once again, no promises on whether we will be able to get support for Python 2.7 out.

[FossenWang]

@brettcannon Hello!
I write an example to support debugging python3.6. Instead of using the pythonFiles/lib/python/debugpy package directly, I use pythonFiles/dispatch_debugpy package to import different versions of debugpy depending on python versions.
Would you like to consider this way?
Here's example code, not fully tested yet, but works on my local machine. Support debugging python 3.6

Maybe it's better to decide debugpy version in ts code, but I'm not familiar with ts, so I only tried this in python.

[GitMensch]

That looks nice, but I'm not sure if the python36 path is "general setup" that will be found in all environments.
Yes, handling this in ts code would likely be preferable, it would at least provide an option to explicit specify python36 (or 27).

[FossenWang]

It seems like there are at least 3 kinds of python paths:

• debugAdapterPython: active interpreter or workspace folder interpreter
• debugLauncherPython: active interpreter or workspace folder interpreter
• debugee python: python config in launch.json

And the adapter, launcher, debugee all use the same debugpy path which is {EXTENSION_ROOT_DIR}/pythonFiles/lib/python by default.
When workspace folder interpreter is different to python config in launch.json, the debugee may use a different version of python from adapter and launcher.

In order to keep debugpy version matching python version, debugpy path and python path should be set in ts code.

[FossenWang]

Here is a solution writing in ts to choose debugpy version according to python version.

If python version is less than 3.7, the debugpy adapter package path is set to "pythonFiles/lib/python36/debugpy/adapter", where the debugpy 1.51 is.

In order to keep debugpy version matching python version, if config "debugAdapterPython" is undefined, config "python" will be set in preference to the lagacy config "pythonPath".

[DoctorYi]

When could we have the nice feature? The VS is not supported for setting fixed extension version for the workspace. And it is realy unconvenient.

[brettcannon]

Any updates here? Does debugpy 1.5.1 allows debugging in python3.6?

We're actively working on getting our new debugging extension to work with debugpy 1.5.1 which supports Python 2.7 and newer. We will announce here once the extension has a version that you can use and test with. If you want to help speed that work up, please use the extension with any Python code you have that supports Python 3.7 and newer to help make sure the debugger code is as stable as possible before we effectively fork it for a one-time release with debugpy 1.5.1.

[paulacamargo25]

We have released the version of the debugging extension that works with debugpy 1.5.1! To use it, install the latest version starting with 2023.1.* on VSCode Insiders. Please help us use the extension with any Python code you have that supports Python 3.6 or lower to help ensure that the debugger code is as stable as possible. Thanks

[brettcannon]

If anyone has time to verify the 2023.1.* versions of https://marketplace.visualstudio.com/items?itemName=ms-python.debugpy work for them when debugging Python 2.7 or Python 3.6 we would really appreciate it! We won't be fixing bugs in older versions of the Python Debugger extension, so once we move on from debugpy 1.5.1 that will be it for supporting those older versions of Python.

If we don't hear from anyone we will assume the extension works fine and move on to do a release with debugpy 1.7 (Python 3.7 and newer) and then shortly thereafter do a release for debugpy 1.8 (Python 3.8 and newer).

[sbidoul]

Hi @brettcannon. I could do a simple python 2 debugging session with the latest vscode, python extension and the latest 2023.1.* of the debugpy extension (stepping through code, inspecting variables). 👍

Does it mean installing the debugpy extension 2023.1.* with the latest python extension is the recommended way to debug python 2 and 3.6? Is it preferred over installing an older version of the python extension itself?

[brettcannon]

Does it mean installing the debugpy extension 2023.1.* with the latest python extension is the recommended way to debug python 2 and 3.6?

Yep!

Is it preferred over installing an older version of the python extension itself?

Also yes!

The idea is that you install the version of the Python Debugger extension that's appropriate/necessary for your version of Python (and FYI we will be shifting all of our debugging over to the separate extension once we feel confident in its stability), but that you can then install whatever version of the Python extension you want, including the latest version (assuming there isn't something in it that you want which no longer works with your version of Python).

[XuShenLZ]

Thanks for your work! When I am trying to debug inside my docker container (with dev container extension), I am still prompted that python version lower than 3.7 is not supported. Am I missing some steps? I tried to hit the debug button, or use "Debugpy: Debug Python File" in command palette, the behaviors are the same

The versions installed inside my dev container:
Python: 3.6.9
Python Extension: v2023.16.0
Debugpy Extension: v2023.3.12621007 (v2023.1.12492010 does not work either)
Debugpy version: 1.5.1

[brettcannon]

Am I missing some steps?

@XuShenLZ Are you using the Python Debugger extension or the Python extension itself? And are you using the appropriate version of the Python Debugger extension?

[XuShenLZ]

Am I missing some steps?

@XuShenLZ Are you using the Python Debugger extension or the Python extension itself? And are you using the appropriate version of the Python Debugger extension?

@brettcannon I have both Python Debugger extension or the Python extension installed. And the versions of them are listed above

Python version: 3.6.9
VS Code Python Extension: v2023.16.0
VS Code Debugpy Extension: v2023.3.12621007 (v2023.1.12492010 does not work either)
Debugpy package version: 1.5.1

It seems that when I hit the "debug" button or "Debugpy: Debug Python File" in the command palette, it still tries to use the Python extension to do that. How should I set it to use Debugpy Extension?

[paulacamargo25]

Thanks for your reply @XuShenLZ, the version 2023.3.* does not support python versions lower than 3.7. Could you try again with the version v2023.1.12492010?(Make sure that this version is installed in the container)
If the bug persist could you create an issue in the Python Extension repo with more information about your system? Thanks

[XuShenLZ]

Thanks @paulacamargo25 . I tested again with version v2023.1.12492010. The good news is that it can work for Python 3.6.9, but the bad news is that I have to use the "RUN and DEBUG" panel on the left to start debugging, rather than the convenient debug button at the right top corner of my python file.

I have brought this up in an issue in the Python Extension repo.

[rvmeer]

Hi, I indeed successfully could debug Python 2.7 code, locally. However, when I go for the attach 'request' in my launch.json, I can not get the breakpoint in my code to hit (i'm using debugpy 1.5.1 on my remote system):

"configurations": [
{
"name": "Python Debugger: Current File",
"type": "debugpy",
"request": "attach",
"connect": {
"host": "localhost",
"port": 5678
},
"pathMappings": [

            {
                "label": "Test scripts",
                "localRoot": "${workspaceFolder}/com/int/tst",
                "remoteRoot": "/usr/home/testfolder"
            }
        ]
    },

On my remote system I start up a SSH tunnel:

ssh -2 -L 5678:localhost:5678 my_remote_host

And I start debugby (1.5.1) on the remote system like:

python -m debugpy --listen 5678 --wait-for-client /usr/home/testfolder/mytest_python27.py

When I run the launch configuration on mytest_python27.py, the remote python script gets executed but breakpoints are not being hit locally.

Is attaching to a remote debugpy 1.5.1 supported?

[brettcannon]

Is attaching to a remote debugpy 1.5.1 supported?

It should when both sides are running the same version of debugpy, but @paulacamargo25 should be able to give a more definitive answer.

[int19h]

From debugpy perspective, it depends on direction of connection, too.

If you're using "connect" in your launch.json and --listen on the debuggee side, all debugpy code is running on the latter, and the remote connection is between the client (VSCode) on one end and debugpy on the other, which is pure DAP and should be supported with any debugpy version.

OTOH if you are using "listen" in launch.json and --connect in the debuggee, you have the debug adapter running on VSCode side and the debug server (pydevd) running remotely. What passes on the wire then is still mostly DAP but there are some bits that are non-standard. This should still mostly work in practice, but I'm not entirely sure that we never broke back-compat for this not-quite-DAP.

Since the scenario described above is the first one, it's more likely that breakpoints not being hit are due to some issues with path mapping, or possibly because the folder is misinterpreted as library code (if so, "justMyCode":false should fix it).

[John-zhan]

Oh no. This kit need to support python2 also

[metamutator]

So here's the summary as I see it:

• Current Debugpy extension v2023.3.13341006 doesn't support Python <= v 3.7
• Somehow, v2023.1.5.1 does.
• However, v2023.1.5.1 isn't available on the extension's website. Only these versions are:

I certainly can't get the debugger to work with a conda environment with Python 3.6 installed:

Is there anything that can be done for us folk who still need to maintain code bases with Python <= 3.7? Happy to play with experimental setups as well.

Thanks!

[brettcannon]

• Current Debugpy extension v2023.3.13341006 doesn't support Python <= v 3.7

Correct.

• Somehow, v2023.1.5.1 does.

Also correct.

• However, v2023.1.5.1 isn't available on the extension's website.

That's sort of correct, sort of not. You're right that version isn't listed, but it's still available. You can follow the instructions at #20184 but for the debugger extension to directly download older versions. But you can select specific versions from the extension sidebar as well and that will list all versions available.

[metamutator]

Thanks! Got it working.

For anyone else dropping by here after a web-search, here are the complete set of steps to debug Python code <=3.7 on Visual Studio Code:

1. Get Visual Studio Code Insiders (Not "regular" Visual Studio Code)
2. Install the Python extension. Right click on the settings icon in the extensions marketplace, and click "Install another version"

3. Choose v2023.22.1 (Other versions may work, but roughly, versions from January 2023 seem to be the last versions that support <= Python 3.7)
4. Search for debugpy again in the Extensions sidebar. Once again, select "Install another version". Choose v2023.1.12492010

5. If you have Visual Studio Code Insiders installed on other laptops like I do (a work/home laptop e.g.), make sure you uncheck "Sync this extension". But don't worry; as the sync is Insiders-to-Insiders, it won't affect your "regular" VS Code setup.
6. Reload if necessary.
7. When you do debug your code, do so via the Run-and-Debug panel, and not the button on the right. Do make sure you select the right conda environment as well (but you know how to do that already, dont you)

The other alternative is to junk this and use PyCharm (which apparently works seamlessly for all Python versions), but where's the fun in doing that. :)

[brettcannon]

1. Get Visual Studio Code Insiders (Not "regular" Visual Studio Code)

This shouldn't be necessary after the next release of VS Code which should be out roughly 2024-02-01.

The other alternative is to junk this and use PyCharm (which apparently works seamlessly for all Python versions), but where's the fun in doing that. :)

Admittedly we could as well (we use the same base debugger and we actually used to fund it's development), but it's a download size trade-off: little over 100 MB or over 500 MB? And this also affects downloading updates to the extension. And w/ the vast majority of our users not needing to download an older version of debugpy, we decided on the smaller, faster, less wasteful approach.

[DoctorYi]

Thanks! Got it working.

For anyone else dropping by here after a web-search, here are the complete set of steps to debug Python code <=3.7 on Visual Studio Code:

1. Get Visual Studio Code Insiders (Not "regular" Visual Studio Code)
2. Install the Python extension. Right click on the settings icon in the extensions marketplace, and click "Install another version"

3. Choose v2023.22.1 (Other versions may work, but roughly, versions from January 2023 seem to be the last versions that support <= Python 3.7) 4. Search for debugpy again in the Extensions sidebar. Once again, select "Install another version". Choose v2023.1.12492010 5. If you have Visual Studio Code Insiders installed on other laptops like I do (a work/home laptop e.g.), make sure you uncheck "Sync this extension". But don't worry; as the sync is Insiders-to-Insiders, it won't affect your "regular" VS Code setup. 6. Reload if necessary. 7. When you do debug your code, do so via the Run-and-Debug panel, and not the button on the right. Do make sure you select the right conda environment as well (but you know how to do that already, dont you) The other alternative is to junk this and use PyCharm (which apparently works seamlessly for all Python versions), but where's the fun in doing that. :)

vS code 1.87 not allowed to use old version of debugger.

[brettcannon]

vS code 1.87 not allowed to use old version of debugger.

Can you be more specific? Extensions can set a minimum VS Code version, but not a maximum.

[DoctorYi]

这是来自QQ邮箱的自动回复邮件。 您好，你的邮件我已经收到。

[brettcannon]

这是来自QQ邮箱的自动回复邮件。 您好，你的邮件我已经收到。

Unfortunately I can't read that.

[DoctorYi]

I tried to install another old version of debugger as advised( Search for debugpy again in the Extensions sidebar. Once again, select "Install another version". Choose v2023.1.12492010), but could not find the version any more

[brettcannon]

I tried to install another old version of debugger as advised( Search for debugpy again in the Extensions sidebar. Once again, select "Install another version". Choose v2023.1.12492010), but could not find the version any more

There was a bug in the marketplace. Please try again.

[DoctorYi]

Hello! ?9?9Thanks for your

[stavnahumg]

Same here vscode : 1.84.2 won't show the 2023.X debugpy versions

[stavnahumg]

4. v2023.1.12492

still only v2024 available, got any info on this behaviour ?

[paulacamargo25]

You can follow the steps here in order to install a pre-release version of the extension.

[brettcannon]

still only v2024 available, got any info on this behaviour ?

A detail that I'm not sure is obvious is you need to opt into the pre-release version of the extension as the older versions of the extension w/ older debugpy releases were released as pre-release. As soon as you switch you will see all of the versions:

(Notice how I filtered the versions to only "2023.1" and you can sort of make out behind the drop-down it says "Switch to Release Version", showing I'm using a pre-release version.)

[brettcannon]

I have opened microsoft/vscode-python-debugger#212 to help make this more clear.