Support `${workspaceFolder}` or `${hostWorkspaceFolder}` #442

chrmarti · 2019-05-24T07:04:59Z

@chrmarti I don't think this particular case is fixed yet. We'd realistically need to support ${workspaceFolder} to get this to work. Unfortunately ${env:PWD} is going to be where VS Code starts, not the workspace location.

This works:

     "workspaceFolder": "/workspace",
    "workspaceMount": "src=/absolute/path/to/where/source/code/is/on/host,dst=/workspace,type=bind"

This doesn't:

     "workspaceFolder": "/workspace",
    "workspaceMount": "src=${workspaceFolder},dst=/workspace,type=bind"

The remote case is supported, but this one requires an absolute path as things are now which really isn't workable - we could close in favor of #306, but it seems to bump up the priority of that one to me at least.

Originally posted by @Chuxel in #41 (comment)

The text was updated successfully, but these errors were encountered:

chrmarti · 2019-05-24T07:37:03Z

We should maybe just tweak PWD. In the docker-compose file we are not going to offer our own variables, but Compose supports environment variables. Using PWD for both would keep us aligned.

Chuxel · 2019-05-24T14:41:49Z

@chrmarti That could work - we should also support CD for the windows case. You'd end up with the following in the example above if you needed to support macOS+Linux and Windows:

    "workspaceMount": "src=${env:PWD}${env:CD},dst=/workspace,type=bind"

We could also just override PWD for Windows, but that could lead to unintended consequences if that env is actually set for a different purpose (since it's not the standard for Windows). We've got the pattern for ~ being ${env:HOME}${env:USERPROFILE} which seems to work. That's already in examples, but we could doc the trick explicitly in tips and tricks section.

joewood · 2019-06-03T13:50:55Z

@Chuxel but if PWD was used for a different purpose in Windows, the above trick wouldn't work, right? You'll end up with that other thing prefixing your current path. So I think we really need the $workspaceFolder fix.

zerdos · 2019-06-05T22:07:08Z

I would remove the workspaceMount from the API - if you have the .devcontainer setup in your repo, you shouldn't mount up any other folder, ever.

With the workspaceFolder - if it is defined, it should override the WORKDIR in the docker file - so we check out the project there, open a new terminal there, etc.

Chuxel · 2019-06-05T22:56:54Z

@zerdos workspaceMount is about replacing the actual source code mount point, not adding a different one. There are two situations where this is needed:

It was added post-release to handle these two common scenarios. Given you can have the mount land anywhere in the container, the workspaceFolder is used to communicate where the VS Code should default -- similar to your WORKDIR example.

Adding an additional volume mount is also quite important for scenarios like docker in docker among others.

DanTup · 2019-06-22T12:29:30Z

I just hit this too. I was spawning an RStudio server in a container, and I need to mount my folder at /home/rstudio but setting workspaceFolder alone doesn't seem to do it (it still mounts at /workspaces/foldername). If I add workspaceMount to control whre it's mounted, I now have to hard-code a full absolute path which makes this repo very not-portable (not just amongst devs, but even between my PC and my MacBook).

If there are possible workarounds in the meantime, I'd be interested to hear :-)

codeman9 · 2019-06-25T19:13:47Z

I worked around this in 2 ways:

I had a shell script that did a sed replacement on some made up variable in the devcontainer.json file. This had the caveat that you had to be careful not to check in the changes since the path would be hardcoded. This setup.sh file was located in the .devcontainer directory and the README mentioned what to do with it.

#!/bin/bash
eval DEV_CONTAINER_JSON='devcontainer.json'
INT_TESTS_TESTS_DIR=$(ls -d "${PWD}/../int-tests/tests")
sed -i.bak s~__INT_TESTS_TESTS_DIR__~"${INT_TESTS_TESTS_DIR}"~g "${DEV_CONTAINER_JSON}"
rm -f "${DEV_CONTAINER_JSON}.bak"

I am now using this in my devcontainer.json file:

	"runArgs": [
		"--volume=/var/run/docker.sock:/var/run/docker.sock",
		"--volume=${env:PWD}/int-tests/tests:/tests",
		"--volume=${env:PWD}/app/build/libs/netfoip/shared:/usr/java/packages/lib"
	]

sandorfr · 2019-07-02T01:00:14Z

Having a WORKSPACE_FOLDER environment variable and workspaceMount expand env variables would definitely help. consistency=cached being almost always necessary to have it work decently on large projects on Macs.

sandorfr · 2019-07-02T01:02:08Z

I had a shell script that did a sed replacement on some made up variable in the devcontainer.json file. This had the caveat that you had to be careful not to check in the changes since the path would be hardcoded. This setup.sh file was located in the .devcontainer directory and the README mentioned what to do with it.

I think I'm going to do something similar as temporary solution. I think I'll have devcontainer.json in .gitignore and commit a devcontainer.json.template.

sandorfr · 2019-07-02T01:05:39Z

@zerdos

I would remove the workspaceMount from the API - if you have the .devcontainer setup in your repo, you shouldn't mount up any other folder, ever.

No I think people with mono repos have valid use cases (mounting a subfolder). Also it's not only about mounting subfolders it's also about options such as consistency.

Numline1 · 2019-07-02T11:25:07Z

I think I'm facing a similar issue but for different reasons. My project got mounted to /workspace/<project_name>. Since it's written in Go, it's necessary for it to be in $GOPATH/src. I've tried fiddling around with the config, and I just assumed "-v", "./:/go/src/project" would work, but that's apparently not a valid syntax for Docker and VSCode starts from / anyway. I ended up using "-v", "${env:HOME}/Projects/socializr:/go/src/socializr" which is not optimal, I don't want to force other team members to create a "Projects" directory within their home dir. It seems that VSCode is using some sort of current dir when mounting the default /workspace/project folder, but it's just not available for users, since we have to define an absolute path?

sandorfr · 2019-07-02T12:00:32Z

. I ended up using "-v", "${env:HOME}/Projects/socializr:/go/src/socializr" which is not optimal, I don't want to force other team members to create a "Projects" directory within their home dir.

yes that defeats the purpose of the whole thing.

sandorfr · 2019-07-03T01:41:26Z

banging my head on another thing, if supporting ${workspaceFolder} is complicated. it should be very easy to make WORKSPACEFOLDER available as an environment variable so we go do something like this:
"-v", "${env:WORKSPACEFOLDER}:/go/src/socializr"

paulbouwer · 2019-07-23T05:45:09Z

Similarly to @Numline1 I'm having to manipulate the workspaceFolder and workspaceMount properties in devcontainer.json for Go projects.

I need the code mounted into the /go/src/<some additional folders> folder in the container. Currently I'm having to hardcode my host path into the src attribute on the workspaceMount property. I only want to have to specify a new workspaceFolder.

I have tried to achieve this a number of other ways but none have worked as well as the hardcoding, I need the workspaceFolder set correctly within VS Code in order for Go to behave well both from the UI and the shell components.

Obviously, hardcoding paths is not the best approach to sharing these setups.

--

So I'd be happy if we could end up with either of the following 2 options:

If you specify workspaceFolder, but don't specify workspaceMount, then the current workspace folder should be mounted into the location specified by workspaceFolder
If you have to specify both workspaceFolder and workspaceMount, then the standard VS Code ${workspaceFolder} variable should be available to use in workspaceMount.

Example 1

The workspace folder open in VS Code will be mounted into the container at /go/src/k8s.io/release and the workspace folder in the container will be set to /go/src/k8s.io/release.

{
  "name": "kubernetes/release",
  "dockerFile": "Dockerfile",
  "runArgs": [
     "--cap-add=SYS_PTRACE",
     "--security-opt", "seccomp=unconfined"
  ],
  "workspaceFolder": "/go/src/k8s.io/release",
  "extensions": [
    "ms-vscode.go"
  ],
  "settings": {
    "go.gopath": "/go"
  }
}

Example 2

The workspace folder open in VS Code (referenced by the ${workspaceFolder} variable) will be mounted into the container at /go/src/k8s.io/release and the workspace folder in the container will be set to /go/src/k8s.io/release.

{
  "name": "kubernetes/release",
  "dockerFile": "Dockerfile",
  "runArgs": [
     "--cap-add=SYS_PTRACE",
     "--security-opt", "seccomp=unconfined"
  ],
  "workspaceMount": "src=${workspaceFolder},dst=/go/src/k8s.io/release,type=bind,consistency=cached",
  "workspaceFolder": "/go/src/k8s.io/release",
  "extensions": [
    "ms-vscode.go"
  ],
  "settings": {
    "go.gopath": "/go"
  }
}

/cc @Chuxel @chrmarti

ermik · 2019-07-26T14:50:21Z

@Chuxel $CD seems to be missing on macOS

ermik · 2019-07-26T15:07:52Z

Also, while environment variables do seem to work, command expansion as in:

{
    "runArgs": [
        "-v", "$(realpath $PWD/../../)"
    ]
}

doesn't seem to work.

chrmarti · 2019-08-16T14:24:05Z

The current suggestion is to go with ${hostWorkspaceFolder} (There is already a workspaceFolder property with the path insider the container.)

Command expansion is tracked as #1050.

ermik · 2019-08-19T13:04:07Z

I agree that we need a different name but semantically this isn't about the host (a storied VM-nomenclature) but rather the local path. host assumes that the source of the directory mounted for remote development is the one hosting the container. That is not the case if I am connecting to a container running in the cloud.

chrmarti · 2019-08-19T14:04:28Z

Good point, although currently there is no way to mount the local folder, the mount will be on the machine where the Docker daemon runs on. What we are introducing is a variable for the folder where the .devcontainer.json or .devcontainer/devcontainer.json originates from. The details of the mount can then still be overridden with the "workspaceMount" option in the devcontainer.json.

With that in mind, maybe localWorkspaceFolder is indeed the better match.

ermik · 2019-08-19T18:08:06Z

So, do we know where something like this is on the roadmap?

Chuxel · 2019-08-19T18:17:17Z

So, do we know where something like this is on the roadmap?

A bit off topic, but Remote - SSH is effectively an amped up Nuclide (both use SSH to connect). There's also a guide on using a remote Docker host for containers. If there's something you're looking for that is not covered, please file a separate issue.

chrmarti · 2019-08-20T09:55:15Z

Going with ${localWorkspaceFolder}.

ermik · 2019-08-20T11:48:39Z

@chrmarti don't miss a chance to tap your inner journalist and leave me a contribline using the commit author annotations. GitHub email is listed on my profile. 😄

paulbouwer · 2019-08-21T07:35:20Z

@chrmarti - so to confirm the new state based on my earlier Example 2. Would the proposed use of ${localWorkspaceFolder} look something like the following:

--

The workspace folder open in VS Code (referenced by the ${localWorkspaceFolder} variable) will be mounted into the container at /go/src/k8s.io/release and the workspace folder in the container will be set to /go/src/k8s.io/release.

{
  "name": "kubernetes/release",
  "dockerFile": "Dockerfile",
  "runArgs": [
     "--cap-add=SYS_PTRACE",
     "--security-opt", "seccomp=unconfined"
  ],
  "workspaceMount": "src=${localWorkspaceFolder},dst=/go/src/k8s.io/release,type=bind,consistency=cached",
  "workspaceFolder": "/go/src/k8s.io/release",
  "extensions": [
    "ms-vscode.go"
  ],
  "settings": {
    "go.gopath": "/go"
  }
}

chrmarti · 2019-08-21T09:08:15Z

@paulbouwer That is correct.

troshko111 · 2019-09-17T21:58:16Z

Is ${workspaceFolder} supposed to be available in settings and postCreateCommand blocks (obviously pointing to the one in the container, i.e. /workspaces/<name>)? It does not seem to be, resolved to empty for me on vscode for Linux 1.38.0 , remote ext version 0.74.0.

chrmarti · 2019-09-18T09:20:30Z

@troshko111 Only ${localWorkspaceFolder} is supported currently.

chrmarti self-assigned this May 24, 2019

chrmarti added containers Issue in vscode-remote containers feature-request Request for new features or functionality labels May 24, 2019

This was referenced May 24, 2019

Add options to control the consistency of the source mount #41

Closed

Support for developing in containers on a remote docker host #171

Closed

Chuxel mentioned this issue Jul 6, 2019

Source code mounts not using cached consistency, Yarn extremely slow #879

Closed

kieferrm mentioned this issue Aug 12, 2019

Remote: Iteration Plan for August 2019 #1135

Closed

24 tasks

egamma changed the title ~~Support ${workspaceFolder}~~ Support ${workspaceFolder} or ${hostWorkspaceFolder} Aug 13, 2019

chrmarti closed this as completed Aug 20, 2019

chrmarti added this to the August 2019 milestone Aug 20, 2019

chrmarti mentioned this issue Aug 27, 2019

Test: ${localWorkspaceFolder} in devcontainer.json #1260

Closed

3 tasks

vscodebot bot locked and limited conversation to collaborators Oct 4, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support `${workspaceFolder}` or `${hostWorkspaceFolder}` #442

Support `${workspaceFolder}` or `${hostWorkspaceFolder}` #442

chrmarti commented May 24, 2019

chrmarti commented May 24, 2019

Chuxel commented May 24, 2019

joewood commented Jun 3, 2019

zerdos commented Jun 5, 2019

Chuxel commented Jun 5, 2019 •

edited

Loading

DanTup commented Jun 22, 2019

codeman9 commented Jun 25, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 2, 2019

Numline1 commented Jul 2, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 3, 2019 •

edited

Loading

paulbouwer commented Jul 23, 2019

ermik commented Jul 26, 2019

ermik commented Jul 26, 2019

chrmarti commented Aug 16, 2019

ermik commented Aug 19, 2019

chrmarti commented Aug 19, 2019

ermik commented Aug 19, 2019

Chuxel commented Aug 19, 2019 •

edited

Loading

chrmarti commented Aug 20, 2019

ermik commented Aug 20, 2019

paulbouwer commented Aug 21, 2019

chrmarti commented Aug 21, 2019

troshko111 commented Sep 17, 2019

chrmarti commented Sep 18, 2019

Support ${workspaceFolder} or ${hostWorkspaceFolder} #442

Support ${workspaceFolder} or ${hostWorkspaceFolder} #442

Comments

chrmarti commented May 24, 2019

chrmarti commented May 24, 2019

Chuxel commented May 24, 2019

joewood commented Jun 3, 2019

zerdos commented Jun 5, 2019

Chuxel commented Jun 5, 2019 • edited Loading

DanTup commented Jun 22, 2019

codeman9 commented Jun 25, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 2, 2019

Numline1 commented Jul 2, 2019

sandorfr commented Jul 2, 2019

sandorfr commented Jul 3, 2019 • edited Loading

paulbouwer commented Jul 23, 2019

ermik commented Jul 26, 2019

ermik commented Jul 26, 2019

chrmarti commented Aug 16, 2019

ermik commented Aug 19, 2019

chrmarti commented Aug 19, 2019

ermik commented Aug 19, 2019

Chuxel commented Aug 19, 2019 • edited Loading

chrmarti commented Aug 20, 2019

ermik commented Aug 20, 2019

paulbouwer commented Aug 21, 2019

chrmarti commented Aug 21, 2019

troshko111 commented Sep 17, 2019

chrmarti commented Sep 18, 2019

Support `${workspaceFolder}` or `${hostWorkspaceFolder}` #442

Support `${workspaceFolder}` or `${hostWorkspaceFolder}` #442

Chuxel commented Jun 5, 2019 •

edited

Loading

sandorfr commented Jul 3, 2019 •

edited

Loading

Chuxel commented Aug 19, 2019 •

edited

Loading