Open gernophil opened 1 year ago
Are you running your filesystem case-sensitive, by chance?
I think I do, but since I did not chance it, it seems to be the default in ventura.
EDIT1: Hmm, the disk utility doesn't say anything about case sensitive, but my zsh for sure behaves like it.
EDIT2: No it's not (see screenshot)
This does not seem to be related to case sensitivity. If I create a simple python file that's called Test/test.py
as well as test/test.py
, I can run the debugger for these files. Also the folders test
and Test
cannot coexist, which proves that my filesystem is not case sensitive.
Maybe it's more related to the fact that the folder has Umlaute (ö
). Unfortunately this cannot be changed, since OneDrive
automatically creates it that way.
Thank you for checking this!
You're right, it looks like this has to do with Unicode composed characters, after all. In the log that you have provided, the "ö" is either composed or not depending on which line of the log it is. The first time it's mentioned, it's composed:
>>> [ch for ch in "OneDrive-Persönlich"]
['O', 'n', 'e', 'D', 'r', 'i', 'v', 'e', '-', 'P', 'e', 'r', 's', 'ö', 'n', 'l', 'i', 'c', 'h']
but then when it logs "Dir Contents", that one uses a combining mark instead:
>>> [ch for ch in "OneDrive-Persönlich"]
['O', 'n', 'e', 'D', 'r', 'i', 'v', 'e', '-', 'P', 'e', 'r', 's', 'o', '̈', 'n', 'l', 'i', 'c', 'h']
Reading up on this, it appears to be happening because macOS filenames are forcibly normalized to NFD form (i.e. the one with combining characters). We don't really do anything special with the names that come from debug config there, so I think it might work if you use the decomposed form of "ö" in your launch.json as a workaround. But we need to handle this normalization on debugpy end.
Thanks for your answer. I'm just starting to use debugpy
. Did use print
statements before that. Seems I need to read up on this. Right now, I have only the default launch.json
and there's no path in it where I could use the decomposed ö
. In addition despite throwing this error it seems, that the Python
file ist still executed. Maybe you could give ma a hint where to start looking.
Otherwise, I'll just use a different folder till you "handle[d] this normalization on debugpy end" :).
If I remember correctly, the default launch.json has something like "program":"${file}"
, which just passes the name of the currently open file to be used. This might actually explain how the non-composed character ended up there in the first place - it might be VSCode itself mangling it, which would probably be a separate bug in its own right.
But you can replace it with "program":"/path/to/file.py"
to point at a specific file, and I think that should give you control over Unicode composition.
I can confirm setting it to
"program":"/Users/username/Library/CloudStorage/OneDrive-Perso\u0308nlich/playground/Git/appName/appName.py"
works. That's a nice workaround, but I have to change it every time I want to debug a different file :). Would be great, if there was a bug fix sometime, even though I understand this won't be your highest priority :).
Yep, this definitely needs fixing. To make the workaround somewhat more palatable I would suggest creating multiple debug configuration profiles for different entrypoints in your app (or different scripts, if you're doing script debugging).
Just figured out, if I change the path to an abspath and run it from the run button, the breakpoints are ignored.
EDIT: This seems to be inconsistent and maybe unrelated. Need to do some more testing.
Don't know what's happening here,but somehow the debugger does not seem to work. Looks like something with the cases is wrong:
OneDrive-Persönlich
vs.onedrive-persönlich
related to this https://github.com/microsoft/debugpy/issues/667?