Setting "workspaceFolder" to "${localWorkspaceFolder}" at devcontainer.json fails on Windows

[vovimayhem]

Currently, I have this in my .devcontainer.json:

{
  "dockerComposeFile": "my-compose.yml",
  "service": "my_app",
  "workspaceFolder": "${localWorkspaceFolder}",
}

And this in my-compose.yml:

version: "3.7"
services:
  my_app:
    image: debian:latest
    command: /bin/sh -c "while sleep 1000; do :; done"
    volumes:
      - .:${PWD} # This is because I want the paths to match in both host and container

This works great on macOS and Linux boxes. However, if I try to open the same project in Windows, this same setup fails:

I think I know what's happening: While on macOS and Linux, ${localWorkspaceFolder} is going to contain a Unix style path, on Windows it will contain a Windows style path, such as C:\Users\myself\Documents\my-app... The thing is, looks like there's no way to fallback to something that works for macOS, Windows and Linux.

I didn't know how to report this (should I open one or several feature requests?), so I decided to go reporting the broken behavior first. But I think this can be worked around if two things happen:

• Enable a version of ${localWorkspaceFolder} in the style of the container's OS - maybe ${localWorkspaceFolderForContainerOS} ?
• Enable a way to set environment variables on whatever shell or stuff you use to launch the devcontainers from the HOST, and let us use them on workspaceFolder like this:

{
  "setLocalEnv": {
    "PWD": "${localWorkspaceFolderForContainerOS}"
  },
  "workspaceFolder": "${localWorkspaceFolderForContainerOS}"
}

My system info:

• VSCode Version: 1.53.2 (user setup)
• Local OS Version: Windows 10 Pro, Version 2004, OS build: 19041.610
• Remote OS Version: Linux a032ad136d9a 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 GNU/Linux
• Remote Extension/Connection Type: Docker (using WSL2 backend)
• Docker version: 20.10.2

Steps to Reproduce:

1. Clone this repository
2. Open the cloned repo locally with Visual Studio Code
3. Open the command palette
4. Select the command ">Remote-Containers: Rebuild and Reopen in Container"

Other info

Does this issue occur when you try this locally?: Does not apply (remote containers required)
Does this issue occur when you try this locally and all extensions are disabled?: Does not apply (remote containers extension required)

[vovimayhem]

OK I saw a couple of articles suggesting opening Code FROM WSL (and looks like something is in the works with #4454), so this issue could be worked around...

However, with WSL there's another issue...

[chrmarti]

Why do you want the local and container paths to match?

Using WSL2 might indeed be an option to avoid the Windows path. This should already work, have you tried?

[github-actions]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[vovimayhem]

@chrmarti I tried it, and yielded better results, but then I got across another problem with that approach... I'll see if I can create another issue with that.

[vovimayhem]

@chrmarti I need the paths to match, because I'm launching other containers from within the first one (I have the docker client installed in the first container, and sharing the docker socket), and the child containers must have a subfolder within the first container... I can't do that the way I need to if I can't make the paths match.

See #4647

[chrmarti]

Marking as feature request. It might be best to retry WSL once I have the fix for that published.

[vovimayhem]

@chrmarti Great! This was the approach I tried first before doing it from WSL (where I got blocked by #4647).

I think the WSL approach is better, but this wouldn't hurt at all for people trying to open this kind of projects directly in Windows.