Proposal: Predefined variables for user's home directory

[AngellusMortis]

We are running into a bunch of issues trying to support all of the use cases for devcontainers:

• VS Code with bind mounts for source ("Reopen in container" after you open the source folder)
• VS Code with code cloned into a container
• Codespaces
• PyCharm

The main hurdle we are hitting is the fact that Windows has a different env for the Home directory then Linux/Mac. If you are doing 1 or 3, it does not matter as much because for Windows you can do from within WSL first. Codespaces is always Linux.

I have seen some other people use both envs but that is still often resulting in a blank env that generates an error:

"mounts": [
        "source=${localEnv:HOME}${localEnv:USERPROFILE}/.docker,target=/home/app/.docker,type=bind,consistency=cached"
]

results in the following if I do "Clone Repository into Container Volume" straight from VS Code on Windows:

docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /.docker.

Having a cross-platform and always defined way of providing the user's home directory on the host machine would help a ton.

(we are getting around the mount point not always existing with an initializeCommand)

"initializeCommand": {
    "mkdir-posix": "mkdir -p $HOME/.config $HOME/.docker $HOME/.cloudflared || true",
    "mkdir-windows": "mkdir %USERPROFILE/.config %USERPROFILE/.docker %USERPROFILE/.cloudflared || true"
},

[samruddhikhandale]

Hi 👋

Thanks for opening the issue.

"${localEnv:HOME}${localEnv:USERPROFILE}" is expected to work across Windows and Linux, as either one must be set depending on the OS.

docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /.docker.

Based on the OS, @AngellusMortis can you double check if HOME or USERPROFILE variables exist on your local machine? If those variables are not set, that's the reason why you are seeing this error ^.

[AngellusMortis]

They exist on the host machine but are not existing inside of the of VS Code or PyCharm/Jetbrains Gateway. Both within the context of cloning the repo inside of a volume. If it is happening within the Docker "host" VM, I am guessing it is because it is not initializing the user envs correctly inside of the VM.

But this is not the first time I have encountered env issues with devcontainers. Way back when they first started with VS Code, there is a bug/issue where it would not initialize your profile correctly on Windows with WSL. I understand you want to try to use the most "standard" solutions to implement global envs and such, but a user's home directory is pretty critical variable that would great to codify into the standard to ensure it is available even if the profile discovery fails / does not run as expected in some cases (like running inside of a Docker Desktop VM on a Windows machine).

[samruddhikhandale]

Thanks for the detailed response.

They exist on the host machine but are not existing inside of the of VS Code or PyCharm/Jetbrains Gateway

It would be great to narrow down this issue to a CLI vs Dev Containers Extension vs a VS Code/Py Charm issue.

Did you try using the @devcontainers/cli to create a container, wondering if that worked? That will help us narrow down the issue, thanks!

It would be great if we can update the CLI and somehow compute the home directory without depending on the host environment variables. However, as the home directory is customizable, I cant think of a standard way which will be compatible with all use cases. Thanks for asking this question, would be an interesting investigation. Let us know if you have any thoughts.

Looping in @chrmarti for additional thoughts.

[AngellusMortis]

So, I did notice a typo and I started doing more testing. It looks like the issue may have actually been some weird caching. The "Clone Repository in Container Volume" seems to have been re-using the existing container volume regardless if I had deleted the old volume with the code cloned on it. So that seems to have resolved the issue with the env not existing, it was probably a typo in an earlier version of the devcontainer config.

I do still think a platform independent way of way of definitely common envs is a good idea though. Having to specify both variables is kind of annoying, but my main blocking issue is "fixed".

However, I did just encounter a new issue since that is finally working. It looks like workspaceMount and workspaceFolder are not working with VS Code's "Clone Repository in Container Volume"

I can move it to a new issue, but figured I would mention it here since you are likely looking at this thread at the moment. Though it probably needs to be moved to a VS Code Dev Containers repo somewhere.

Using Windows 11 22H2 (build 22621.2428) with VS Code 1.83.1 and Docker Desktop 4.22.1.

Config:

    "workspaceFolder": "/home/vscode/dev",
    "workspaceMount": "source=${localWorkspaceFolder},target=/home/vscode/dev,type=bind,consistency=cached",

Log snippnet:

[7803 ms] Start: Run in container: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.315.1/dist/spec-node/devContainersSpecCLI.js read-configuration --workspace-folder /workspaces/test-devcontainer --id-label vsch.local.repository=https://github.com/AngellusMortis/test-devcontainer.git --id-label vsch.local.repository.volume=test-devcontainer-363594d37f57d6ac29db4272eefdce7d73f1a69605ff3da4269ad89334a13dcd --id-label vsch.local.repository.folder=test-devcontainer --id-label devcontainer.config_file=/workspaces/test-devcontainer/.devcontainer/devcontainer.json --container-id 7de52b50a2e96cb9c28d66645187a83dcd21ae28a5d69244491cd0de480562c5 --log-level debug --log-format json --config /workspaces/test-devcontainer/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-a3894a74-9956-4607-a614-05289f560923.json --include-merged-configuration --mount-workspace-git-root --terminal-columns 216 --terminal-rows 25

Test repo to reproduce: https://github.com/AngellusMortis/test-devcontainer

Full Logs: https://gist.github.com/AngellusMortis/594326ce92bc52970e64b95b78824f64

You can see there is no reference to /home/vscode/dev in the logs, only the default location (/workspaces/test-devcontainer).

It also only happens with the "Clone Repository in Container Volume" feature in VS Code so I assume it is a VS Code issue (well issue with the extension). Looking at the CLI docs, this definitely looks like a VS Code issue, not a devcontainers CLI issue (as seen in the log snippet above as well). Just let me know what repo to move the issue over to if you want.

[AngellusMortis]

It also turns out that JetBrains IDEs do not handled the empty envs. ${localEnv:HOME}${localEnv:USERPROFILE} will resolve to /home/user${localEnv:USERPROFILE}. I know their implementation of dev containers is still pretty experimental as well though.

[chrmarti]

workspaceFolder not being respected when using a volume is tracked in microsoft/vscode-remote-release#3034.

[jan-hudec]

"${localEnv:HOME}${localEnv:USERPROFILE}" is expected to work across Windows and Linux, as either one must be set depending on the OS.

Problem is that there are cases where you need to set HOME on Windows for some other software ported from Unix, so it's not guaranteed HOME will not be set on Windows. I my case it was usually trying to make git-bash, msys2 and/or cygwin work together correctly, because while git-bash is based on msys2, it is configured slightly differently.

[ibis-hdl]

I run into the same issue. The problem seems to be related to WSL2 - there isn't a variable USERPROFILE, hence it will fail on Docker using WSL2. I'm using devcontainer on Windows with VS Code to get an Ubuntu-24 developer environment.

[Fydon]

I can create a new issue, but I think this is relevant. I'm using vscode. On macOS both HOME and USERPROFILE are defined and contain the same value. I have a Windows and macOS computer, so could drop ${localEnv:HOME} from the mount, but it would be nice to have a cross-platform option for open-source projects.

[trajano]

"${localEnv:HOME}${localEnv:USERPROFILE}" is expected to work across Windows and Linux, as either one must be set depending on the OS.

This is not reliable and will fail if someone creates an environment variable HOME on Windows.

[trajano]

It would be best if there's just ${localHomeDirectory} that is provided rather than the hack.

[AngellusMortis]

You are beating a dead horse. Microsoft does not actually care how needed/useful a feature is anymore. Only how many upvotes it gets and how much AI they can shove into it.