Setting `GOPATH` for each vscode project

Setting the GOPATH variable global as an enviroment variable works fine with Visual Studio Code.

But setting a project specific variable globally doesn't seem very nice to me. Consider you have multiple Go projects, you would have to change this variable each time you, compile, debug, ... etc. a project.

Is there a possibility to set the GOPATH variable as a project variable in Visual Studio Code? Ether in settings.json or launch.json?

(Q2 2018:
Note that with the vgo project, GOPATH might end up being deprecated in favor of a project-based workflow. That would avoid the manual project-based GOPATH I was proposing below, two years ago)

With Go 1.11 (August 2018), GOPATH can be optional, with modules.

It is more and more supported with VSCode:

• vscode-go/issue 1532
• "Go modules support in Visual Studio Code"

In addition to vendor folder, you still can have one GOPATH per project.

See "GOPATH from go.inferGopath setting":

> ## GOPATH from go.inferGopath setting

> Setting go.inferGopath overrides all of the above.
If go.inferGopath is set to true, the extension will try to infer the GOPATH from the path of the workspace i.e. the directory opened in vscode. It searches upwards in the path for the src directory, and sets GOPATH to one level above that.

> For example, if your project looks like /aaa/bbb/ccc/src/..., then opening the directory /aaa/bbb/ccc/src (or anything below that) will cause the extension to search upwards, find the src component in the path, and set the GOPATH to one level above that i.e. GOPATH=/aaa/bbb/ccc.

> This setting is useful when you are working on different Go projects which have different GOPATHs. Instead of setting the GOPATH in the workspace settings of each project or setting all the paths as ;/: separated string, you can just set go.inferGopath to true and the extension uses the right GOPATH automatically.

> ## GOPATH for installing the Go tools using go.toolsGopath

> By default, all the dependent Go tools are used from the GOPATH derived from the above logic.
If they are available on your PATH, the PATH is used to locate the Go tools.
If the Go tools are not in your path, you might end up with the same Go tools installed in each of your GOPATHs.
To prevent the Go tools from cluttering your GOPATH, use the go.toolsGopath setting to provide a separate location for the Go tools.

> The first time you set go.toolsGopath, you will have to run Go: Install Tools command so that the Go tools get installed in the provided location.

The GOPATH is your workspace and it's divided in

GOPATH/
    |- bin/
    |- pkg/
    |- src/ <--- your projects are saved here
        |- .../my_project1
        |- .../my_project2

With this separation, your don't need to set a new GOPATH for each project. I recommend you read How to Write Go Code

set workspace settings, in windows:

1. goto settings: ctrl+,

2. set workspace setting:

    { 
         "go.gopath": "d:\\gopath;E:\\src"
    }
   

use ; for multiple path

3. restart visual studio code to take effect.

Go 1.5 added the vendor directory that allows a per-project dependency management.

>If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that path names a directory containing at least one file with a name ending in “.go”.

source

This feature has been enabled by default with Go 1.6:

>Go 1.5 introduced experimental support for a “vendor” directory that was enabled by an environment variable. In Go 1.6, the feature is now enabled by default.

source

Even with the 1.6 version, depending on the tools you use, you might need to set the GO15VENDOREXPERIMENT environment variable to 1 (export GO15VENDOREXPERIMENT=1 on unix-based OS)

If your VSCode project directory is organized,

1. go to Settings
2. either search "Infer Gopath" or find this entry under Extensions/Go
3. check the box

Then VSCode infers GOPATH from your workspace root, which solves my problem immediately. I believe this is explained in other answers. I am posting this just to give a shorter version.