This sounds like https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/1890170 - from the various reports there, it looks like cv2 might have some conflicts with other packages employing native code?

<!-- Please search existing issues to avoid creating duplicates. -->

Environment data

• VS Code version: 1.47.3
• Extension version (available under the Extensions sidebar): v2020.7.96456
• OS and version: Windows 10

The doc of debug configuration has changed pythonPath to python in https://github.com/microsoft/vscode-docs/pull/3560, but python doesn't seem to be valid:

Also the default value is now ${command:python.interpreterPath} (https://github.com/microsoft/vscode-python/issues/11789#issuecomment-631413067) instead of ${config:python.pythonPath} provided in the doc.

Using ${config:python.pythonPath} will give error when start debugging:

At the same time, using ${command:python.interpreterPath} is inconsistent with "python.pythonPath" in workspace's settings.json.

Duplicate of #12462

The docs are correct in this case, but the extension doesn't reflect it in the schema.

It also needs changes to all code paths in the extension that get or set "pythonPath" in the debug configuration.

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

When I use the debugger on a Python file (via F5), the Python Debug Console opens in a new terminal. It would be great to have the option to have the Python Debug Console open in an existing active terminal. The reason for this is that I use Remote to develop on a shared cluster. My workflow is: I request a machine for an interactive job, so my terminal is attached to a specific machine. However when I run the debug command, the Python Debug Console opens a new terminal on the main node of the cluster rather than on the machine I'm using for the interactive job. Thank you!

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Done!! -->

Environment data

VSCode Help copy:

• Version: 1.46.1 (system setup)
• Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
• Date: 2020-06-17T21:13:20.174Z
• Electron: 7.3.1
• Chrome: 78.0.3904.130
• Node.js: 12.8.1
• V8: 7.8.279.23-electron.0
• OS: Windows_NT x64 10.0.18362- VS Code version: XXX

Other

• Extension version (available under the Extensions sidebar): 2020.6.91350
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.6 (Win 64-vit)
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: all
• Relevant/affected Python-related VS Code extensions and their versions: python and maybe all?
• Value of the python.languageServer setting: microsoft

Expected behaviour

When debugger stops, it highlights the line it is actually stopped at.

Actual behaviour

Debugger stops at the same line the breakpoint is at, but it appears to be at a different line in the code, but only when word wrap is enabled, and there are lines that have word-wrapped higher up in the file. It does appear that the number of lines that the highlighting is off by increases with more lines word-wrapping above that point (the effect is somehow cumulative).

Steps to reproduce:

Please see this vscode issue for more details. They requested logging this for the Python extension since that's where I found the issue. I have detailed screenshots of a specific example, etc.

1. Enable word wrap (set option to 'on', see other issue for details)
2. Create a python script with some lines that force wordwrap, and have some for loops with if/elif/else in them (to be able to notice the highlighting being on the wrong rows as you step through the loop, etc.)
3. Ensure that many lines cause a wordwrap on the screen (make the editor narrow enough and/or a few lines long enough (just add comments?)
4. Set a breakpoint and debug the code. The initial debug will appear to stop at the location of the breakpoint, but may not actually be there.
5. step through the code, especially through some if/else and for loop blocks. The highlight will appear to be on the wrong line when jumping from the end of the loop to the start, or moving through the if/else blocks.

More details at the vscode issue linked above.

<!-- Note: If you think a GIF of what is happening would be helpful, consider tools like https://www.cockos.com/licecap/, https://github.com/phw/peek or https://www.screentogif.com/ . -->

Please re-open if it turns out to be a distinct issue.

Issue Type: <b>Bug</b>

I recently started using Cryptomator to encrypt my files locally before they are uploaded to the cloud (so if someone somehow gains access to my could storage, they still won't be able to access the actual files). This works by storing the files inside a "vault" mounted on some drive letter (e.g. V:). If I understand correctly, that drive is considered a network drive by the OS. The files on that vault are then automatically encrypted and saved in the folder used by the cloud service.

I noticed that if a Python program is located anywhere on this virtual drive V:, then VS Code cannot debug it. I set breakpoints, but the execution never actually breaks on those breakpoints; it simply runs the whole program from beginning to end without breaking.

Steps to reproduce:

1. Using VS Code, open any Python program stored on the local disk. (The content of the program itself doesn't seem to matter. For concreteness let's go with "print(2+2)".)
2. Set a breakpoint with F9 and press F5. The execution will break at that point.
3. Close VS Code.
4. Copy that same program to a folder on the Cryptomator vault (drive V:) and open it using VS Code.
5. Set a breakpoint with F9 and press F5. Now the execution will NOT break at that point.

Note: I also tried debugging a C++ program in the same folder, and had no issues; this problem seems to be specific to Python.

Python version: 3.8.5 64-bit Extension version: 2020.7.96456 VS Code version: Code 1.47.3 (91899dcef7b8110878ea59626991a18c8a6a1b3e, 2020-07-23T13:12:49.994Z) OS version: Windows_NT x64 10.0.19041

Closing as duplicate of #200 - we'll track any further work on this there.

That's basically what #200 is about. But it's not quite so trivial, because individual folders can be case-sensitive (and their subfolders can, in turn, be case-insensitive) - fixing it properly means that the debugger can no longer case-normalize paths as a whole, but needs to do so separately for every path step, so there are perf implications, as well.

The latter one is the expected behavior (it can't find the IDE side, but that's okay).

Does C:\Program Files\ArcGIS\Pro\bin\Python\envs\dev\python.exe work for you in general when used manually, e.g. to run a simple hello world type script?

Also, judging by the path, this is actually a conda environment - these usually require activation via conda activate before they can be used. I'm not entirely sure how this applies to ArcGIS, though (i.e. where the conda command is located). But if you can figure it out, try running VSCode itself from a terminal where conda activate succeeded.

It's interesting that it didn't produce a server log. What happens if you manually run this in the terminal?

'C:\\Program Files\\ArcGIS\\Pro\\bin\\Python\\envs\\dev\\python.exe' 'c:\\Users\\eykampC\\.vscode\\extensions\\ms-python.python-2020.7.96456\\pythonFiles\\lib\\python\\debugpy' '--connect' '127.0.0.1:63737' '--configure-qt' 'auto' '--adapter-access-token' '64123f9f109fb4c0d3243e365fd401c6b6b24c019445608c6c15552c8f25e6a0' 'c:\\dev\\PIMS - dev\\delme2.py'
    

Those old issues from the ptvsd repo shouldn't be relevant here. But it probably does have something to do with ArcGIS Python. We'll need the logs to figure that out, though. Can you please add this:

"logToFile": true

to your debug config, and then look for debugpy*.log in c:\Users\eykampC.vscode\extensions\ms-python.python-2020.7.96456?

What's the command line like in the terminal?

If you're using "console": "internalConsole" in launch.json, change to "console": "integratedTerminal" and try like that.

@fabioz, is this fundamentally the same as #200, or was there something else special about network drives?

Environment data

• VS Code version: 1.47.2
• Extension version (available under the Extensions sidebar): v2020.7.94776
• OS and version: MacOS 10.15.5
• Python version (& distribution if applicable, e.g. Anaconda): Anaconda 3.6
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

Expected behaviour

All process are killed when debugger is stopped / terminated.

Actual behaviour

Not all processes are stopped when debugger is terminated. I observed this pattern only when debugging multiprocess application like Flask, Celery. It leaves one zombie process running behind. I'll have to manually kill this process.

Steps to reproduce:

1. Code

from flask import Flask
app = Flask(__name__)
app.run(host="0.0.0.0", port=5000, threaded=True, debug=True)

2. launch.json

        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "subProcess": true,
        },

3. Start the debugger and terminate after it starts. The below process is left behind:

501 46232     1   0  9:52PM ??         0:11.50 xxxx/bin/python xxxx/.vscode/extensions/ms-python.python-2020.7.94776/pythonFiles/lib/python/debugpy/_vendored/pydevd/pydevd.py --module --port 50912 --ppid 46228 --client 127.0.0.1 --client-access-token xxxx --multiprocess --json-dap-http --file test_debugpy

4. When you try to debug the same file again without killing the zombie process, you will get Address in use exception.
5. This happens when debugging other multiprocessing applications/libraries like celery.

https://github.com/microsoft/debugpy/pull/359 should take care of this, as well.

If you compare it to the path for the breakpoint (in the Breakpoints pane), are there any obvious differences, e.g. in variable case? We've seen some issues in the past that were caused by VFS on Windows breaking the usual case-insensitive path behavior.

Yep! For more details, see this section in Python docs.

Is this specific to OneDrive, or are you also seeing it with non-Latin paths elsewhere on the filesystem?

Also, when you use "stopOnEntry": true, and it breaks, what does the path look like in the Call Stack pane?

If you use breakpoint(), does it stop? And if so, what is the path to the file that you see in the Call Stack pane?

The important part is calling main() from under the guard - freeze_support() is just a part of the standard verbiage that's written to be as platform-independent as possible.

Linux does indeed fork by default, but it can also use spawn via set_start_method(). Your call stack above - the one with multiprocessing/spawn.py in it - indicates that to be the case.

VSCode Version: 1.42.1

OS Version: Ubuntu 18.04

Steps to Reproduce:

• Comment "--noreload" in launch.json
• Press Ctrl + F5 to run the django process.
• Click "stop(Shift + F5)" button to stop all django processes.
• But there is still a process (pid 23069) that has not been closed.
• And its parent process become 1 from 23064

This happens sporadically, and can affect any test for which the debuggee process exits quickly. In some cases, it can exit before the adapter gets a chance to report the "process" event. The adapter sends "terminated" in this case, but the tests always wait for "process" first, and so time out.

On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits.

On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits.

Improve process tree autokill tests to actually check whether the child process has exited.

It should generally be at the end of your script, and all top-level code that's not already in a function should be inside main(). The reason is that your script is going to be imported as a module in every subprocess that multiprocessing spawns, so any top-level code will run many times without the guard. But only the instance that's directly started as a script will have __name__ == "__main__".

Can you show more of the call stack and/or error traceback? I'm curious as to what was calling into runpy - normally you wouldn't call it with a path pointing into site-packages.

Removing "argsExpansion" due to #13264.

Removing "argsExpansion" due to #13264.

Possibly another manifestation of #346 - note that this is also Python 3.7.

Im trying to do something like

command: -c "pip3 install debugpy -t /tmp && python3 /tmp/debugpy --wait-for-client --listen 0.0.0.0:5678 -c </glue/bin/gluesparksubmit /opt/src/main.py>"

I see in file https://github.com/microsoft/debugpy/blob/4331cf54c0156338d5179b8f5f54126035d448c5/src/debugpy/server/cli.py#L320 - there is a 'run_code' method that might be the general idea of what i am trying to achieve but not sure this is intended use.

Yep, there's an outstanding PR for that - we just need to coordinate a few more things for it to go in.

(https://github.com/microsoft/vscode-python/issues/11678)

The "argsExpansion" property allows the user to enable or disable shell expansion of arguments passed to the debuggee via the "args" property. Valid values are "none" and "shell".

If set to "shell" (default), when the app is run in integrated or external terminal, the arguments are passed via shell in that terminal, and various glob and substitution patterns (*, ? globs, $... variable expansion etc) are applied by that shell. For example, assuming Linux+bash, this:

"args": ["/bin/*sh"],
"argsExpansion": "shell" // or omitted

would result in the debugged app seeing something like this in sys.argv:

["/bin/bash", "/bin/dash", "/bin/rbash", "/bin/rzsh", "/bin/sh", "/bin/zsh"]

If set to "none", the arguments are passed directly, circumventing the shell. Thus, in the example above, the app will see ["/bin/*sh"] in sys.argv.

The latter is useful for apps that do their own glob expansion - usually when the arguments are not meant to be filenames. For example, the standard unittest module allows matching tests by class/function name with a glob: -k test_*bar will match test_foobar. But if shell expansion is enabled, then the shell itself will try to expand that * as if it were a filename, and fail because there are no files matching the pattern.

The feature itself has been regressed due to recent VSCode changes, and it's unclear whether we can implement it. It's not going to be surfaced in the Python extension for now, so it shouldn't be doc'd. I'll reopen if we find a way to light it up again.

https://devguide.python.org/#status-of-python-branches https://devguide.python.org/devcycle/#end-of-life-branches # Python 3.5 EOLs in one month.

We're not accepting any more changes to ptvsd; https://github.com/microsoft/debugpy is the new hotness.

But in any case, we do not strictly follow the official EOL dates. They are taken into consideration, but it's not the most important thing. Even if something is EOL'd, but still has a lot of users - e.g. Python 2.7 - we keep supporting it.

The debugger itself doesn't handle envfiles; it only understands "env". The extension processes "envFile" before the debug session begins, and converts it to "env" entries. In particular, it merges PATH and PYTHONPATH, rather than replacing them.

But also, I don't see why it'd matter? Regardless of what's in PYTHONPATH, sys.path[0] always be the entry dynamically created by Python when launching a script file, and should be the directory in which that script file is located. So, for python .../pythonFiles/testlauncher.py, it should always be .../pythonFiles. If it's something else, I think we need to figure out why that's happening.

I'd start by printing out sys.args, os.getcwd(), and os.environ in the test launcher, to see what the difference is between the debug and the non-debug case.

See https://github.com/microsoft/vscode-python/issues/13264

The option might still be useful for other clients, but the issue highlights the fact that its current name is very client-behavior-specific, and doesn't accurately represent what it does: whether pass the arguments to the debuggee directly, or via the terminal. It should be called something like "argsFormat" or "argsPassing" instead.

Until that's decided, the option as is should not be considered stable, and the docs should reflect that.

It always behaves as "none" now, because VSCode started escaping arguments in "runInTerminal" request: https://github.com/microsoft/vscode/issues/98471

There's no way for debugpy to work around this, so until VSCode provides the functionality necessary to do it, we should disable the property in the extension (i.e. remove it from the launch.json schema).

With respect to "runInTerminal" shell being an implementation detail - I don't think users see it that way. They see the terminal and the shell during launch, and they know that it uses the default shell they configured in the settings, so there's no obvious reason as to why access to features of that shell is so restricted.

If the launch command were passed to the shell as an argument (bash -c ... etc), instead of "typed" as input in the terminal, such that the command is not visible at all, I think that would truly make the shell an implementation detail, and lower those expectations. That would also mean that the terminal automatically exits once debug session is over, however. From our perspective, this is actually preferable, because those leftover debug terminals end up confusing the users (they often don't even notice that it's a new terminal, different from the one they were using before for manual CLI work, and just continue to use it as such).

My apologies for a belated follow-up!

This issue has an interesting history. Originally, our implementation of the debug adapter propagated debuggee arguments via command line, and thus VSCode's lack of escaping resulted in shell expansion for them. It was not really an intended decision on our part, but our users have discovered it, and started using it as such, as we later found out.

When we rewrote the debug adapter, one of the changes was argument handling - now they were propagated as raw JSON from the "launch" request via a socket. This disabled shell escaping, and we got user complaints about this, e.g. https://github.com/microsoft/debugpy/issues/86 (also an example of a scenario that this feature inadvertently enabled).

Since the change was technically breaking, and we knew that we had users relying on past behavior, we re-implemented argument passing again. But because we already ran into a scenario where shell quoting was not desirable, this time it was made configurable - by default, we reverted back to old behavior of using the shell to pass them, but users could say "argsExpansion": "none" in launch.json to circumvent the shell.

Unfortunately, this change on VSCode side effectively broke our setting, since now it doesn't matter anymore whether the arguments are passed via the shell or not. Which also means that the bug linked above has to be re-opened, since it has been regressed - but we no longer have the means to fix it.

I think it's reasonable to not have shell expansion by default - it can be confusing to users who are unfamiliar with it, and are just trying to pass a string to their app, not to mention being shell-specific; and, on the other hand, the scenarios where it's useful are advanced ones, and so the user can be reasonably expected to know (or read the docs to find out) that they need to enable it. But as it is, we're basically breaking a bunch of launch.json setups that worked fine before, and for which there's no different way to do what they were doing - there are no workarounds here, so far as I can see.

So, my suggestion is to provide some way to reflect this configurability in the "runInTerminal" request, so that debug adapters can make use of it to request escaping if needed, and surface it in their "launch" request schema. It would be even better if it can be done on an argument-by-argument basis, instead of the setup that we had, where the setting applied to all arguments at once. If it all goes into "args", it would be easier for debug adapters to use, as well, since they could just marshal the config setting as is (i.e. wouldn't have to figure out the syntax and semantics for their own setting), with only such additions as the adapter needs to launch the debuggee.

Corresponding to https://github.com/microsoft/debugpy/issues/305.

For #13218

• [x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
• [x] Title summarizes what is changing.
• [x] Has a news entry file (remember to thank yourself!).
• [x] ~Appropriate comments and documentation strings in the code.~
• [x] ~Has sufficient logging.~
• [x] ~Has telemetry for enhancements.~
• [x] ~Unit tests & system/integration tests are added/updated.~
• [x] ~Test plan is updated as appropriate.~
• [x] ~package-lock.json has been regenerated by running npm install (if dependencies have changed).~
• [x] ~The wiki is updated with any design decisions/details.~

There's currently no way to specify interpreter command line arguments without also specifying the interpreter binary - both are done via "python". When used with VSCode, this means that there's no easy and obvious way to use the current selected interpreter in the IDE, but add some arguments to it - one needs to know about ${command:python.interpreterPath} (and I'm not sure this is even guaranteed to not get renamed or removed in future versions?).

We can enable this scenario by providing a separate property to specify just the arguments, similar to "args" for the debuggee itself, and "debugpyArgs" for injected debugpy; the obvious name would be "pythonArgs".

This should work in conjunction with existing semantics for "python" to maintain compatibility - if "python" is an array, and "pythonArgs" is also present, then we just concatenate them in that order to obtain the final value.

Expose "pythonArgs" to clients.

Make "python" usable in tests in lieu of "pythonPath", and make the runners use it.

Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

@luabud I can also edit the description for "pythonPath" to be consistent. :)

Since you're debugging a library installed into site-packages, you need to set "justMyCode": false - does that help?

Keep in mind that they'll see "args" in the list first, long before they get to this one. I don't think it's very likely that someone will get confused by the tooltip alone... and we always have docs for the detailed descriptions.

This looks like it should just be import os?

@luabud Please check the wording. I wasn't sure what the most appropriate term to use here, because "pythonPath" description says "executable", but then we seem to be using "interpreter" elsewhere a lot - more consistently so in more recent additions to the extension.

For #13218

• [x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
• [x] Title summarizes what is changing.
• [x] Has a news entry file (remember to thank yourself!).
• [x] ~Appropriate comments and documentation strings in the code.~
• [x] ~Has sufficient logging.~
• [x] ~Has telemetry for enhancements.~
• [x] ~Unit tests & system/integration tests are added/updated.~
• [x] ~Test plan is updated as appropriate.~
• [x] ~package-lock.json has been regenerated by running npm install (if dependencies have changed).~
• [x] ~The wiki is updated with any design decisions/details.~

#13218 is now intended as the one and only way of supplying arguments to the interpreter, so "python": [...] shouldn't be exposed in the extension - only scalar string values.

(debugpy will still support the array syntax for backwards compatibility)

Corresponding to https://github.com/microsoft/debugpy/issues/305.

Expose "pythonArgs" to clients.

Make "python" usable in tests in lieu of "pythonPath", and make the runners use it.

Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

The real problem here is command line escaping, or lack thereof. Briefly, in cmd.exe, for historical reasons, the following is valid:

dir/s/q

and is the same as:

dir /s /q

There are many convoluted rules there that affect this behavior, and it's not really worthwhile trying to figure them all out. We should just avoid APIs like exec() that take command line argument as a single string - those should do appropriate quoting.

So, basically, always either execFile() or spawn() (with shell: true if needed - it defaults to false for both). But exec() should be an extremely rare case - I doubt we have any scenarios where it's necessary. Any scenario that does justify it, also justifies a lengthy code comment explaining why it's needed :)

And shell: true should only be set if needed, because it's expensive to spawn them, and they introduce more moving bits that can potentially fail. Like, in this case, it would be needed because we're running a batch script on Windows (but perhaps we can avoid that?).

Sorry, looks like I messed up the notification settings for the repo.

I would like the option of an interactive prompt after a debug run completes. Like when running a script with the "-i" parameter: "python.exe -i myscript.py"

I tried adding "-i" as an argument in the launch.json, but the parameter does not seem to work with the debugger, it causes multiple errors and the script does not run.

If you're adding the argument directly to "pythonPath" in launch.json, i.e. something like "python -i", that won't work - it is treated as a path to the Python binary in its entirety, including any spaces etc, so those are not argument delimiters.

To be able to do this with VSCode, you'll have to wait until we implement https://github.com/microsoft/debugpy/issues/305.

@wuyudi, please try the workaround in https://github.com/microsoft/debugpy/issues/346#issuecomment-663803934 while we investigate.

@fabioz, this might be another manifestation of the root cause #346 - repros in VSCode on 3.7 (i.e. with native bits), but not on 3.8.

Furthermore, repro does depend on where exactly breakpoints are set - in my experiments, it requires breakpoints on lines 2 and 3, but having it on 3 alone works fine. So I think there's some interaction between those two that causes the conditional logic behind the iterator to take a wrong path somewhere.

Debugger does spawn background threads - that's an unavoidable part of the implementation. However, you wouldn't see those threads in the Call Stack window. They are also not running your code, so "executing the same code several times simultaneously" does not apply. Same thing goes for subprocesses.

This behavior doesn't reproduce for me on any simple app, so we'll need some more information to repro. Most likely, this has more to do with the code being debugged, or with the libraries that it uses.

In addition, I'm curious as to what lead you to conclude that those threads execute the same code. Did you try pausing and inspecting the call stacks in other threads to see what code is running there? If not, doing that might shed some light on what's spawning the threads.

The crucial requirement for the repro is Python 3.7, although I suspect this has more to do with us only shipping Cython binaries for that.

@fabioz, can you take a look? It might be a rare corner case, but changing behavior of running code like that is very concerning.

The problem with such features is that if they try to be too smart, they end up doing the wrong thing that kinda sorta works, until it doesn't. I suspect that this is exactly how you ended up with those from nw ... imports - because PyCharm helpfully "corrected" your code (which didn't need correction!).

It would probably be easiest to just set it as a global environment variable - that way it'll also apply to "attach" sessions.

The error message "stdin: is not a tty" does not originate from conda. It originates from bash, or rather more specifically, from a common (and, arguably, broken) bash setup that tries to run mesg without checking whether the shell is running in a tty context or not first. Here is a lengthy explanation - note that there's no Python in the picture at all.

But anyway, the message is actually a warning. The problem is that it's printed to stderr, and it looks like the code that's invoking exec() here treats any stderr output as a fatal error. If it simply ignored that message, I think activation would have worked just fine.

Infinite expansion is not an issue with the debugger - it just faithfully reports what attributes the object has; and in this case, the data attribute seems to be recursively referencing itself.

This is by design of Python itself - specifically, how it handles sys.path.

As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter.

Or, in other words, when you do:

python ./nw/build_view_file.py

the first entry on sys.path isn't going to be . - it's ./nw. Thus, when you later do:

from nw.build_views import build_views

it won't be able to find package nw, because you're inside the directory that constitutes said package.

In other words, if you're running a Python file as a script, and it expects to import modules and packages, those modules and packages should be located alongside the script. In this case, since build_view_file.py uses nw as a package, it needs to be in the workspace folder itself.

Although I don't think nw is intended as a package, given that it's missing __init__.py, and given that you're importing app and app.models directly in the same Python script without trying to qualify them with nw. In which case, that line should properly read:

from build_views import build_views

(and you also need to do the same with all your other scripts that do import nw or from nw ...).

Note that this all has nothing to do with the debugger. The only thing to be aware of is that "file": ".../foo.py" in your launch.json behaves exactly as python .../foo.py would, including wrt sys.path.

I think this one is about reporting the error clearly at this point.

Those other issues are separate, because the debugger itself already works on ARM platforms, just not the native bits like attach-to-PID. So there's no reason why we shouldn't be running CI on ARM today already, if we could easily do that.

Can you try setting PYDEVD_USE_FRAME_EVAL=NO in environment variables, and see if that helps? Since you're launching the program using the debugger, you should be able to set it via "env" in launch.json.

It looks like https://github.com/microsoft/vscode/issues/98471 regressed this on VSCode side. Need to clarify if this is the intended behavior.

We don't have clear evidence that one or the other is preferable by default. There was one beta of debugpy which didn't do any expansion, and there were bugs filed about it, as well. We're sticking to pre-existing behavior on the basis that it's at least what more users are familiar with, whether they prefer it or not.

I couldn't readily repro it with these steps, unfortunately. It might be that there's some hidden variable at play here....

Can you check something on your repro? When you step through the program, if you have the Run view open, you should be seeing line numbers in the Call Stack section. Do they reflect the highlighted line in the editor? Or are they correct, but the editor is highlighting the wrong line?

@willwhitney I think you're hitting https://github.com/microsoft/vscode-remote-release/issues/2806