4 ms·

For this extension to work, you need to install several Go tools in GOPATH. How did you manage your GOPATH across multiple projects? Do you have a single GOPATH

For this extension to work, you need to install several Go tools in GOPATH. How did you manage your GOPATH across multiple projects? Do you have a single GOPATH for every project or each project has its own GOPATH?

KyleBrandt 11y ago
I set my GOPATH to my home dir, and only use a single GOPATH for all projects. This way things are where you might expect relative to your home dir (If thinking in FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). For example, executables end up in ~/bin, everything else is in ~/src. Never had any issues with this setup.
blinkingled 11y ago
Gaah, I thought this will provide me with some motivation to try writing some Go code but can't even get started with installing the analysis tools - cannot find package "golang.org/x/tools/go/types". Anyway will debug that one later but if anyone has a hint, go ahead.
- lukehoban 11y ago
  If the automated install of the analysis tools doesn't work, you can always just manually install them into your GOPATH. See https://github.com/Microsoft/vscode-go#tools https://github.com/Microsoft/vscode-go#tools.
  - blinkingled 11y ago
    Thanks, but manual install fails with same error for golint and goreturns. I ended up git cloning into my %GOPATH%\src\golang.org\x from https://go.googlesource.com/tools https://go.googlesource.com/tools and https://go.googlesource.com/net https://go.googlesource.com/net - that seems to have fixed it.
schmichael 11y ago
At work we have a monorepo and therefore a single GOPATH (we use a tool called glock for dependency pinning). A monorepo a fantastic way to live, but I totally understand that it doesn't work for everyone.
mseepgood 11y ago
> Do you have a single GOPATH for every project or each project has its own GOPATH? Yes, a single GOPATH/workspace for all projects, as it is described here: https://golang.org/doc/code.html#Overview https://golang.org/doc/code.html#Overview
jzelinskie 11y ago
I have a single $GOPATH per project and always recommend doing so. If you vendor code with a tool like godep[0], having one shared $GOPATH is a nightmare. Other tools might work better, but this is basically the standard for the projects I work on. I basically just have a zsh alias[1] that combines z[2] and sets the $GOPATH to $PWD split on "src". I do share a single $GOBIN set to $HOME/bin, though. [0]: https://github.com/tools/godep https://github.com/tools/godep [1]: https://github.com/jzelinskie/dotfiles/blob/04ad026f30782189644125a92f0e527f11bec5a0/.zshrc#L40 https://github.com/jzelinskie/dotfiles/blob/04ad026f30782189... [2]: https://github.com/rupa/z https://github.com/rupa/z
- nulltype 11y ago
  I have a similar setup, but I actually alias the go command itself so I don't have to type anything special.
- KyleBrandt 11y ago
  Using govendor with my stuff and a shared GOPATH. I haven't noticed an issue, I wonder what makes it a nightmare for you?

KyleBrandt 11y ago

I set my GOPATH to my home dir, and only use a single GOPATH for all projects. This way things are where you might expect relative to your home dir (If thinking in FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). For example, executables end up in ~/bin, everything else is in ~/src. Never had any issues with this setup.

blinkingled 11y ago

Gaah, I thought this will provide me with some motivation to try writing some Go code but can't even get started with installing the analysis tools - cannot find package "golang.org/x/tools/go/types". Anyway will debug that one later but if anyone has a hint, go ahead.

lukehoban 11y ago
If the automated install of the analysis tools doesn't work, you can always just manually install them into your GOPATH. See https://github.com/Microsoft/vscode-go#tools https://github.com/Microsoft/vscode-go#tools.
- blinkingled 11y ago
  Thanks, but manual install fails with same error for golint and goreturns. I ended up git cloning into my %GOPATH%\src\golang.org\x from https://go.googlesource.com/tools https://go.googlesource.com/tools and https://go.googlesource.com/net https://go.googlesource.com/net - that seems to have fixed it.

schmichael 11y ago

At work we have a monorepo and therefore a single GOPATH (we use a tool called glock for dependency pinning). A monorepo a fantastic way to live, but I totally understand that it doesn't work for everyone.

mseepgood 11y ago

> Do you have a single GOPATH for every project or each project has its own GOPATH? Yes, a single GOPATH/workspace for all projects, as it is described here: https://golang.org/doc/code.html#Overview https://golang.org/doc/code.html#Overview

jzelinskie 11y ago

I have a single $GOPATH per project and always recommend doing so. If you vendor code with a tool like godep[0], having one shared $GOPATH is a nightmare. Other tools might work better, but this is basically the standard for the projects I work on. I basically just have a zsh alias[1] that combines z[2] and sets the $GOPATH to $PWD split on "src". I do share a single $GOBIN set to $HOME/bin, though. [0]: https://github.com/tools/godep https://github.com/tools/godep [1]: https://github.com/jzelinskie/dotfiles/blob/04ad026f30782189644125a92f0e527f11bec5a0/.zshrc#L40 https://github.com/jzelinskie/dotfiles/blob/04ad026f30782189... [2]: https://github.com/rupa/z https://github.com/rupa/z

nulltype 11y ago
I have a similar setup, but I actually alias the go command itself so I don't have to type anything special.
KyleBrandt 11y ago
Using govendor with my stuff and a shared GOPATH. I haven't noticed an issue, I wonder what makes it a nightmare for you?