Hacker News Reader

Comment by iainmerrick | Hacker News Reader

I seem to recall hearing that was finally being fixed, but a quick search of the docs suggests not. I think it's just GOROOT (another bizarre idea) rather than GOPATH that's no longer strictly required in the latest version of Go.

I agree with you, I don't understand why GOROOT couldn't just be the directory containing the compiler, and GOPATH couldn't just be the current directory. Maybe make me put some kind of workspace file there to identify it as the project root, that'd be fine.

View on HN

> I seem to recall hearing that was finally being fixed, but a quick search of the docs suggests not. I think it's just GOROOT (another bizarre idea) rather than GOPATH that's no longer strictly required in the latest version of Go.

GOPATH is set to `~/go` by default, and if your projects use vendoring (which they should), you can almost completely ignore that it exists. Packages in `./vendor/` will take precedence over anything in your GOPATH.

Do most Go programmers put all their code under ~/go, or do they tend to set GOPATH on a project-by-project basis?

Most put it under ~/go. It's quick and easy.

Most set the GOPATH. It's quick and easy.

Quite a few current Go programmers will have something set other than `~/go` because that default only came in very recently, but you'll probably find that almost everyone uses `~/go` or `$GOPATH`.

One thing that you learn quickly when starting Go is that fighting the language's idioms (even where they're questionable) isn't going to be a good time.

Yeah, that's pretty much why I haven't learned Go. :)

Don't know about others, but since I run my projects in containers anyway, I'll usually use `direnv` on my host to set GOPATH to project directory, and then use the default GOPATH in go docker images (`/go`).

I could even do without direnv altogether, but I need it so that vim-go can report build errors on file saving.

I use virtualgo[0] so I can organise my work properly and not mix my own stuff up with loads of unrelated libraries

[0] https://github.com/getstream/vg

> if your projects use vendoring (which they should)

For versioning? Also:

1. I haven't seen projects on github using vendoring

2. It doesn't look like `go get` allows you to download a package directly into your vendor file

For my personal project [1] I use vendoring. But as of Go 1.8 it is still inconvenient as the main package has to be on GOPATH/GOROOT or the compiler will not find it.

To maintain it I use git-subrepo [2], a very convenient tool to embed the code into own tree.

[1] - https://github.com/ibukanov/ljdumpgo

[2] - https://github.com/ingydotnet/git-subrepo

Have a look at /coreos on GitHub -- flannel, dex and prometheus-operator all use vendoring, just looking at what's pinned. matchbox does also.

Thanks for the examples!

https://github.com/coreos/flannel/tree/master/vendor

For the Go tools to work consistently, your code has to be inside GOPATH, which means you cannot ignore it entirely.

You can often use relative package names (e.g. "go test ./..."), but it breaks whenever you use absolute ones, and the Go toolchain is based on this assumption being true. My experience is that editor plugins (e.g. the Go plugin for VSCode) don't like this.

I use hardlinks (the "hln" third-party utility on macOS) to get around this, which means I can have all my projects under a sane directory structure under ~/Projects.

Reply on news.ycombinator.com