Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
brettcannon opened this issue Jul 26, 2022 · 50 comments
Assignees
Labels
area-debugging community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs spike Label for issues that need investigation before they can be worked on.

Comments

@brettcannon
Copy link
Member

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).

@brettcannon brettcannon added feature-request Request for new features or functionality area-debugging needs spike Label for issues that need investigation before they can be worked on. community ask Feature request that the community expressed interest in labels Jul 26, 2022
@brettcannon brettcannon changed the title Break out debugging support into its own extension Break out debugging support into its own extension (to support Python 3.6 debugging) Jul 27, 2022
@brettcannon brettcannon pinned this issue Jul 27, 2022
@brettcannon brettcannon changed the title Break out debugging support into its own extension (to support Python 3.6 debugging) Bring back Python 3.6 debugging support by breaking debugging out into its own extension Jul 27, 2022
@aamarin
Copy link

aamarin commented Oct 15, 2022

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
Copy link
Member Author

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
Copy link

nutu commented Dec 16, 2022

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
Copy link
Member Author

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

Python 3.7.

@yanjieee
Copy link

v2022.6.3 working fine

@GitMensch
Copy link

GitMensch commented Apr 11, 2023

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
Copy link
Member Author

@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 added a commit to FossenWang/vscode-python that referenced this issue Apr 13, 2023
@FossenWang
Copy link

FossenWang commented Apr 13, 2023

@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
Copy link

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
Copy link

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
Copy link

FossenWang commented Apr 17, 2023

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
Copy link

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.

@XuShenLZ
Copy link

XuShenLZ commented Sep 21, 2023

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

image

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
Copy link
Member Author

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
Copy link

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
Copy link

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
Copy link

XuShenLZ commented Oct 4, 2023

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
Copy link

rvmeer commented Nov 29, 2023

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
Copy link
Member Author

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
Copy link

int19h commented Dec 4, 2023

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
Copy link

Oh no. This kit need to support python2 also

@metamutator
Copy link

metamutator commented Jan 15, 2024

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:
image

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

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
Copy link
Member Author

  • 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
Copy link

metamutator commented Jan 19, 2024

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"
image
  1. 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)
  2. Search for debugpy again in the Extensions sidebar. Once again, select "Install another version". Choose v2023.1.12492010
image
  1. 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.
  2. Reload if necessary.
  3. 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)
image

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
Copy link
Member Author

  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
Copy link

DoctorYi commented Feb 4, 2024

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"
image 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 image 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) image 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
Copy link
Member Author

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
Copy link

DoctorYi commented Feb 5, 2024 via email

@brettcannon
Copy link
Member Author

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

Unfortunately I can't read that.

@DoctorYi
Copy link

DoctorYi commented Feb 6, 2024

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
image

@brettcannon
Copy link
Member Author

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
Copy link

DoctorYi commented Feb 6, 2024 via email

@stavnahumg
Copy link

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

@stavnahumg
Copy link

4. v2023.1.12492

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

@paulacamargo25
Copy link

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

@brettcannon
Copy link
Member Author

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:

image

(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
Copy link
Member Author

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

@paulacamargo25
Copy link

I'll close this issue since the Python Debugger is already in production, feel free to submit a feature-request pr bug report in the Python Debugger Extension Repository.

@DoctorYi
Copy link

DoctorYi commented Jun 26, 2024 via email

@karthiknadig karthiknadig unpinned this issue Jul 24, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-debugging community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs spike Label for issues that need investigation before they can be worked on.
Projects
None yet
Development

No branches or pull requests