microsoft / microsoft/vscode-python-debugger

Unexpected configuration merging behavior for justMyCode debugging option

Offen
#749 4 Kommentare 0 Reaktionen 2 zugewiesene Personen Auf GitHub ansehen

@rchiodo arbeitet bereits daran.

Seit 14.8.2025.

triage-needed
Vorherrschende Sprache
TypeScript
Sterne
181
Forks
126
Ø Merge
2 T. 3 Std.
Gemergte PRs (30 T.)
3

Beschreibung

In #139, many people have reported being unable to use justMyCode as expected. While there is a workaround in the linked comment, I believe it ultimately stems from the global debugpy.debugJustMyCode overwriting the launch configuration option, which I think is unexpected.

I had always been relying on the launch-configuration-level setting of justMyCode being set to false to be sufficient. Is the extension perhaps not merging the different levels of configs as expected and leading to the default debugpy.debugJustMyCode to trump the launch-configuration-level justMyCode when specified in .code-workspace files?

Originally posted by @tboddyspargo in #139

I wanted to repost this here in an effort to specifically focus on the question of configuration merging behavior.

I expect the repro to be something like:

  1. Specify a python special purpose file or test debug configuration (with "justMyCode": false) in the launch configuration of a .code-workspace file.
  2. Open that workspace and debug a python script using that launch configuration.
  3. Try to step into library code using the debugger
  4. Based on my previous experience and the other reports in #139, I expect this to not go into library code during the "subsequent" debug sessions (frame skipped message?)

However I also think that, even without repro-ing, it may be reasonable to re-examine the config merging behavior of debugpy.debugJustMyCode with workspace-level launch configuration settings to definitively debug the root cause hypothesis here or confirm it.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.