7 ms·

> 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 th

> 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.

iainmerrick 9y ago
Do most Go programmers put all their code under ~/go, or do they tend to set GOPATH on a project-by-project basis?
- bacongobbler 9y ago
  Most put it under ~/go. It's quick and easy.
  - foo101 9y ago
    Most set the GOPATH. It's quick and easy.
- clra 9y ago
  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.
  - iainmerrick 9y ago
    Yeah, that's pretty much why I haven't learned Go. :)
- oelmekki 9y ago
  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.
- petepete 9y ago
  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 https://github.com/getstream/vg
baby 9y ago
> 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
- fpoling 9y ago
  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 https://github.com/ibukanov/ljdumpgo [2] - https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo
- kensey 9y ago
  Have a look at /coreos on GitHub -- flannel, dex and prometheus-operator all use vendoring, just looking at what's pinned. matchbox does also.
  - baby 9y ago
    Thanks for the examples! https://github.com/coreos/flannel/tree/master/vendor https://github.com/coreos/flannel/tree/master/vendor
lobster_johnson 9y ago
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.

iainmerrick 9y ago

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

bacongobbler 9y ago
Most put it under ~/go. It's quick and easy.
- foo101 9y ago
  Most set the GOPATH. It's quick and easy.
clra 9y ago
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.
- iainmerrick 9y ago
  Yeah, that's pretty much why I haven't learned Go. :)
oelmekki 9y ago
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.
petepete 9y ago
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 https://github.com/getstream/vg

baby 9y ago

> 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

fpoling 9y ago
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 https://github.com/ibukanov/ljdumpgo [2] - https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo
kensey 9y ago
Have a look at /coreos on GitHub -- flannel, dex and prometheus-operator all use vendoring, just looking at what's pinned. matchbox does also.
- baby 9y ago
  Thanks for the examples! https://github.com/coreos/flannel/tree/master/vendor https://github.com/coreos/flannel/tree/master/vendor

lobster_johnson 9y ago

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.