vscode-docker
vscode-docker copied to clipboard
microsoft
Linux style containerPath with "dockerRun": { "os": "Windows" }
docker uses Linux style containerPath for Python container debugging:
docker run -dt ... -v "d:\Users\[user]\.vscode\extensions\ms-python.python-2021.11.1422169775\pythonFiles\lib\python\debugpy:/debugpy:ro" ...
It should be C:\debugpy, not /debugpy
Similar .Net container creates windows style path:
docker run -dt ... -v "D:\Users\[user]\vscode\netcorerest:C:\app:rw"
In both cases tasks.json has "dockerRun": { "os": "Windows", … }
Is there a way to change generated containerPath command?
Or it is a bug... or behavior by design?
vscode Version: 1.62.0 (user setup) Commit: b3318bc0524af3d74034b8bb8a64df0ccf35549a Date: 2021-11-03T15:23:01.379Z Electron: 13.5.1 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.17763
docker extension v1.17.0
I guess this is a bug but we never really expected anyone to do Windows contains for Python.
Brandon,
I guess this is a bug but we never really expected anyone to do Windows contains for Python.
Right, there is python windows server based container... Looks good to use in VS code :)
Could you clarify a couple things, please?
- Is "container style path" in a config somewhere or hardcoded?
- Does is suppose to take into account "dockerRun": { "os": "Windows", … } (but not done yet) or the setting is for something else?
- Is "container style path" in a config somewhere or hardcoded?
In this instance it's hardcoded here: https://github.com/microsoft/vscode-docker/blob/main/src/tasks/python/PythonTaskHelper.ts#L128. In comparison, the .NET task helper checks that property to decide the path style for the container volume mappings: https://github.com/microsoft/vscode-docker/blob/main/src/tasks/netcore/NetCoreTaskHelper.ts#L210
- Does is suppose to take into account "dockerRun": { "os": "Windows", … } (but not done yet) or the setting is for something else?
Currently that flag is used only for .NET containers (to determine the destination path style for the implicit volume mappings used by debugging, and to determine what flavor of vsdbg to download) but AFAIK there's no reason it can't also be used in the Python task helper. We would need to investigate what else might need to be done to enable debugging Python apps in Windows containers; e.g. I think changes will also be needed here: https://github.com/microsoft/vscode-docker/blob/main/resources/python/launcher.py#L17 and https://github.com/microsoft/vscode-docker/blob/main/src/scaffolding/wizard/python/PythonGatherInformationStep.ts#L12
Brandon, Thanks a lot for clarifications!
In this instance it's hardcoded here
I.e. no way to overwrite it... right?
Looks like nobody ever asked for it, there is no demand for these updates, actually? IMO, it should be sufficient to clarify it in docs and tutorials, (at least for now).
I.e. no way to overwrite it... right?
Yeah, unfortunately 😞. We have some logic that will let users override implicit bindings, but it works based on destination--i.e. if the destination within the container is the same, we take the user's input. However, since you'd have to override a Linux path with a Windows path, it's not possible to have the same destination.
Looks like nobody ever asked for it, there is no demand for these updates, actually? IMO, it should be sufficient to clarify it in docs and tutorials, (at least for now).
@ucheNkadiCode what do you think (Python debugging in Windows containers)? Worth an investigation at least right?
Brandon,
However, since you'd have to override a Linux path with a Windows path, it's not possible to have the same destination.
Got it!
Uche, I'll help with testing if you want to give it a try.
Hey @ecc256, thanks for your suggestion! We are going to wait to see if there is more customer demand before deciding to work on this. ~In the mean time, this workaround will suffice.~
Thanks!
@ucheNkadiCode
In the mean time, this workaround will suffice.
Which one exactly? :)
@ucheNkadiCode
In the mean time, this workaround will suffice.
Which one exactly? :)
Whoops! I'm sorry, I got confused with a separate issue 😅
If working with python Windows containers is not planned, so what is the alternative for cross platform python development?
We'd recommend using Linux containers even if you are on a Windows host.
We'd recommend using Linux containers even if you are on a Windows host.
AFAIK, it's not possible with WSL1. WSL2 requires nested virtualization. It's available on AWS metal instances only and they are very expensive.
Are you using the AWS instances for development or the actual production service host? If it's for production hosting, I'd be shocked if there weren't cheaper options for container hosting than a Windows VM.