5 ms·

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after I figured out some hacks that I could use to avoid it.

jadeklerk 9y ago
Because you didn't want to set an env var?
- merb 9y ago
  GOPATH has a default. Unix: $HOME/go Windows: %USERPATH%/go but on ci servers it could be akward.
- chimeracoder 9y ago
  > Because you didn't want to set an env var? You haven't needed to set a GOPATH since 1.8, which was released over a year ago (we're now at 1.10). Since 1.8, the Go toolchain will use a default GOPATH; the environment variable is only needed as an override.
- lloeki 9y ago
  The problem is not the env var, because whether or not it was set or with a default value, you have to clone the project https://github.com/foo/bar.git https://github.com/foo/bar.git at ~/go/src/github.com/foo/bar and name the imports github.com/foo/bar accordingly and run the go commands from there. I used to (automatically) just export GOPATH="${PWD}/.gopath" but this doesn't work anymore since 1.8 or 1.9. People† at large just want to clone https://github.com/foo/bar.git https://github.com/foo/bar.git wherever they see fit, like directly at ~/Workspace/bar, ~/work/bar, ~/projects/contrib/bar or even /tmp/bar. † "People" includes CI systems that expect the typical "clone and cd straight into" thing to work, resulting in a lot of boilerplate and/or symlink hacks to work around such expectations.
ovao 9y ago
For what reasons did you need to avoid it?
- eberkund 9y ago
  Some people want to store their projects in their own folder structure and not be forced to store it in the very weird way Go does it. I didn't avoid Go for this reason but I did find the whole Go workspace way it does things a big turnoff.
warent 9y ago
I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational. Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high. The same applies for Gofmt as well.
- Sir_Cmpwn 9y ago
  I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".
  - dasacc22 9y ago
    I've been working with Go for 6 years, your complaints are not "totally naive and irrational". I don't mind GOPATH, but I did argue that if vendoring was to be a thing then it needed to be dropped entirely. I was also not a fan of the vendoring mechanism. The approach given here looks much more thought out getting rid of each, first proposal I've actually liked.
  - Groxx 9y ago
    This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.
    - neoasterisk 9y ago
      Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.
      - 9y ago
fiatjaf 9y ago
You say that because you have infinite filesystem space. I don't.
- Sir_Cmpwn 9y ago
  Though GOPATH avoids duplication, it's entirely possible to avoid duplication without GOPATH.
  - Groxx 9y ago
    And downloading the full Git repository for every `go get` is frequently a far greater waste than even storing copies of all the versions you're currently using in all projects you work on. GOPATH is unambiguously terrible.
    - fiatjaf 9y ago
      you're right.
clinta 9y ago
GOPATH was weird to get used to at first, but I gave in and I actually store all my projects, even non-go projects, in the same folder hierarchy now. It has made me much more organized. In fact here's a zsh function I have for cloning new projects into that structure. It makes my home directory much less of a mess. gclone() { dir=$(echo $1 | sed 's/^http$s*$:\/\///g' | sed 's/^git@//g' | sed 's/\.git$//g' | sed 's/:/\//g' ) git clone $1 "$HOME/src/$dir" cd "$HOME/src/$dir" }

jadeklerk 9y ago

Because you didn't want to set an env var?

merb 9y ago
GOPATH has a default. Unix: $HOME/go Windows: %USERPATH%/go but on ci servers it could be akward.
chimeracoder 9y ago
> Because you didn't want to set an env var? You haven't needed to set a GOPATH since 1.8, which was released over a year ago (we're now at 1.10). Since 1.8, the Go toolchain will use a default GOPATH; the environment variable is only needed as an override.
lloeki 9y ago
The problem is not the env var, because whether or not it was set or with a default value, you have to clone the project https://github.com/foo/bar.git https://github.com/foo/bar.git at ~/go/src/github.com/foo/bar and name the imports github.com/foo/bar accordingly and run the go commands from there. I used to (automatically) just export GOPATH="${PWD}/.gopath" but this doesn't work anymore since 1.8 or 1.9. People† at large just want to clone https://github.com/foo/bar.git https://github.com/foo/bar.git wherever they see fit, like directly at ~/Workspace/bar, ~/work/bar, ~/projects/contrib/bar or even /tmp/bar. † "People" includes CI systems that expect the typical "clone and cd straight into" thing to work, resulting in a lot of boilerplate and/or symlink hacks to work around such expectations.

ovao 9y ago

For what reasons did you need to avoid it?

eberkund 9y ago
Some people want to store their projects in their own folder structure and not be forced to store it in the very weird way Go does it. I didn't avoid Go for this reason but I did find the whole Go workspace way it does things a big turnoff.

warent 9y ago

I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational. Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high. The same applies for Gofmt as well.

Sir_Cmpwn 9y ago
I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".
- dasacc22 9y ago
  I've been working with Go for 6 years, your complaints are not "totally naive and irrational". I don't mind GOPATH, but I did argue that if vendoring was to be a thing then it needed to be dropped entirely. I was also not a fan of the vendoring mechanism. The approach given here looks much more thought out getting rid of each, first proposal I've actually liked.
- Groxx 9y ago
  This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.
  - neoasterisk 9y ago
    Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.
    - 9y ago

fiatjaf 9y ago

You say that because you have infinite filesystem space. I don't.

Sir_Cmpwn 9y ago
Though GOPATH avoids duplication, it's entirely possible to avoid duplication without GOPATH.
- Groxx 9y ago
  And downloading the full Git repository for every `go get` is frequently a far greater waste than even storing copies of all the versions you're currently using in all projects you work on. GOPATH is unambiguously terrible.
  - fiatjaf 9y ago
    you're right.

clinta 9y ago

GOPATH was weird to get used to at first, but I gave in and I actually store all my projects, even non-go projects, in the same folder hierarchy now. It has made me much more organized. In fact here's a zsh function I have for cloning new projects into that structure. It makes my home directory much less of a mess. gclone() { dir=$(echo $1 | sed 's/^http$s*$:\/\///g' | sed 's/^git@//g' | sed 's/\.git$//g' | sed 's/:/\//g' ) git clone $1 "$HOME/src/$dir" cd "$HOME/src/$dir" }