Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

go

I am new to Go programming language and every tutorial starts off from setting GOPATH to current project folder.

Am I missing something? Is programmer really supposed to set GOPATH manually when he cd to his new Go project folder? I have read several FAQ entries about GOPATH but still couldn't wrap my head around it.

And why does GOROOT exist then? What's its purpose?

Are there any automatic tools which detects if current directory is root folder of Go project (for example by some hidden file) and changes GOPATH to this directory automatically?

Thank you, any advice really appriciated

ps. For example I develop completely disjoint Go projects A, B and C, should they live in single "workspace" environment? I guess not, but what I should do with GOPATH and GOROOT then?

like image 504
Nik Avatar asked Jun 19 '14 12:06

Nik


People also ask

What is the purpose of a Gopath environment variable in Golang?

The GOPATH environment variable specifies the location of your workspace. It defaults to a directory named go inside your home directory, so $HOME/go on Unix, $home/go on Plan 9, and %USERPROFILE%\go (usually C:\Users\YourName\go ) on Windows.

What should Gopath be?

GOPATH defaults to $HOME/go . You only need to set it explicitly if you want to put it somewhere else. This location can be overridden using the GOBIN environment variable.

Do we need to set Gopath?

Since Go 1.8, you don't need to set your GOPATH or GOROOT. GOPATH by default is under your user/home directory.

What is Goroot used for?

GOPATH and GOROOT are environment variables that define a certain arrangement and organization for the Go source code. The paths of gopath and goroot can be modified explicitly if required.


3 Answers

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.

like image 82
Elwinar Avatar answered Oct 16 '22 23:10

Elwinar


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.

like image 26
Rick-777 Avatar answered Oct 17 '22 00:10

Rick-777


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.

like image 9
Inanc Gumus Avatar answered Oct 17 '22 00:10

Inanc Gumus