Can someone explain why GOPATH is convenient and how it should be used in general?

The goal of the GOPATH is to centralize all packages into one common workspace. It is not really a new concept by itself (think of the Java Classpath for example), but Go's use is drastically simpler by not supporting packages versioning.

The Go programmer isn't supposed to set GOPATH manually when entering a new project folder. Each project folder is supposed to be a package by itself, and reside in the GOPATH along other packages, so GOPATH should be set only once. Tutorials begin by setting the GOPATH in order to isolate the tutorial workspace from anything else (or simply assuming that a user hasn't set the GOPATH, yet).

GOROOT is set to provide the standard packages to the Go programmer, you don't need to do anything with it. In short, there is a single rule for GOROOT: never, ever, touch it. Don't install anything in it, don't modify standard packages, etc.

I'm not aware of a tool to detect Go projects in the current directory, but it shouldn't be highly complex to create.

How you handle different projects is up to you. The Go way is to put every project as a package in the $GOPATH/src directory and do everything from there. As I don't really like it, I defined my GOPATH to be $HOME/.go. Then I put each project in a dedicated directory somewhere else (anywhere in my computer), and symlink the project directory into my $GOPATH/src dir. I can then use every Go toolchain command (e.g. go build myproject), use the project as package for another one, etc.

GOPATH allows you to collect dependency source code and the resulting compiled binaries in one place. This seems like a really attractive idea. However, I found myself working on several totally unrelated Go projects and an alternative approach suited me better.

This is a similar but different strategy to Elwinar's symlnks. I start a new project in an empty folder and create src. And I drop into the folder this shell script called env.sh:

if [ `type -p go` = "" ]; then
    export PATH=$PATH:/usr/local/go/bin
fi
export GOPATH=$PWD
export PATH=$PATH:$PWD/bin

Each time I start work, I use

. env.sh

Note the dot and space - they matter.

Now, everything I do on this project is localised within this folder. It's possibly not the most widely-used strategy, but it works well for me.

And another thing: if your dependencies make use of environment variables for testing etc, you can put them in env.sh too. For example, Gorp has

export GORP_TEST_DSN=test/testuser/TestPasswd9
export GO_TEST_DSN=testuser:TestPasswd9@/test

Addendum

In the most recent Go versions, GOPATH is optional; if you don't set it, the default is $HOME/go. If you do set it and also want to use the new modules feature, set GO111MODULES=on also.

You don't need to set your GOPATH or GOROOT. GOPATH by default is under your user/home directory.

If no GOPATH is set, it is assumed to be $HOME/go on Unix systems and %USERPROFILE%\go on Windows. If you want to use a custom location as your workspace, you can set the GOPATH environment variable.

Go Modules

Now there's Go Modules support (since Go 1.11), so you don't have to use GOPATH anymore. For example, you can go to any directory on your system (outside of $GOPATH), and you can initialize a new Go module there, then you start working there. No GOPATH is needed.

You just need to do this once (while in a directory):

go mod init

$GOPATH: Go stores these files under it:

• Source files ($GOPATH/src)
• Compiled package files ($GOPATH/pkg)
• Runnable files ($GOPATH/bin)

$GOROOT: Where the Go source code resides like Go Standard Library.

Also to run any go installed executable file from anywhere on your system, you might want to add $GOPATH/bin to your path environment variable like this:

export PATH=$PATH:$(go env GOPATH)/bin

More information check out this.