4 ms·

Is no one else annoyed about the GOPATH pedantry ?

by simula67 9y ago

__david__ 9y ago
I am too. I spend way too much of my time hacking around stupid GOPATH issues.
- sethammons 9y ago
  I've been using Go as my primary language now for a few years. I never change nor have issues with GOPATH. Now, older applications that are using godep for vendoring still, that is something I have lost far too much time against.
sonaltr 9y ago
That's one of the first issues I've had with Go. To the point where, all my go projects are something along the following lines: projectname: |- go |-- src |--- domain.com |---- username |----- projectname |------ Actual Code goes here... |-- pkg |-- bin It's a fun time explaining this to anyone new on the team...
- sethammons 9y ago
  Is that what you are checking into source control? For every project I work on, the projectname directory is where .git lives. It so happens that when I 'go get', it goes into the whole structure you reference above based on my one GOPATH that I never, ever change. For those new to Go, you just show them how it works once. For those used to Go, there are no surprises.
  - sonaltr 9y ago
    I'd check the internal folder (projectname/go/src/domain.com/username/projectname) into source control (domain.com/username/projectname). Everyone has a different way they like to setup their environment and I didn't want to push my ideas onto other users.
    - sethammons 9y ago
      I acknowledge that everyone has a different way they like to setup their environment. If they choose to do it the way that the designers intended, then they suddenly don't have many of the issues that many folks complain about around GOPATH and standard build tooling works as expected. The way you reference is a valid way, but is unorthodox and requires altering GOPATH for each project. If one is worried about polluting a global space of packages as they pull in dependencies (the standard objection), that is what vendoring is for. If someone is not liking all the fuss with altering GOPATHs, that particular grumbling is easy to fix: don't alter it :) When I first started with Go, I did the whole "alter the GOPATH for each project," until I finally gave in. After, things just got simpler. To each their own.
randomdata 9y ago
Are you referring to how modern versions of the Go toolchain do not require GOPATH to be set and are able to build projects in any directory? I don't see an issue with it.
- andyfleming 9y ago
  I knew that there was now a default for GOPATH, but I didn't know you are able to build in any directory. When was that added?
  - randomdata 9y ago
    Honestly, I'm not sure. I don't follow development that closely. It works with 1.10, possibly earlier versions.
  - petre 9y ago
    The Go 1.10 release notes mentioned it. That was on 16 feb, which was last thursday. https://golang.org/doc/go1.10#goroot https://golang.org/doc/go1.10#goroot

Is no one else annoyed about the GOPATH pedantry ?

__david__ 9y ago

I am too. I spend way too much of my time hacking around stupid GOPATH issues.

sethammons 9y ago
I've been using Go as my primary language now for a few years. I never change nor have issues with GOPATH. Now, older applications that are using godep for vendoring still, that is something I have lost far too much time against.

sonaltr 9y ago

sethammons 9y ago
Is that what you are checking into source control? For every project I work on, the projectname directory is where .git lives. It so happens that when I 'go get', it goes into the whole structure you reference above based on my one GOPATH that I never, ever change. For those new to Go, you just show them how it works once. For those used to Go, there are no surprises.
- sonaltr 9y ago
  I'd check the internal folder (projectname/go/src/domain.com/username/projectname) into source control (domain.com/username/projectname). Everyone has a different way they like to setup their environment and I didn't want to push my ideas onto other users.
  - sethammons 9y ago
    I acknowledge that everyone has a different way they like to setup their environment. If they choose to do it the way that the designers intended, then they suddenly don't have many of the issues that many folks complain about around GOPATH and standard build tooling works as expected. The way you reference is a valid way, but is unorthodox and requires altering GOPATH for each project. If one is worried about polluting a global space of packages as they pull in dependencies (the standard objection), that is what vendoring is for. If someone is not liking all the fuss with altering GOPATHs, that particular grumbling is easy to fix: don't alter it :) When I first started with Go, I did the whole "alter the GOPATH for each project," until I finally gave in. After, things just got simpler. To each their own.

randomdata 9y ago

Are you referring to how modern versions of the Go toolchain do not require GOPATH to be set and are able to build projects in any directory? I don't see an issue with it.

andyfleming 9y ago
I knew that there was now a default for GOPATH, but I didn't know you are able to build in any directory. When was that added?
- randomdata 9y ago
  Honestly, I'm not sure. I don't follow development that closely. It works with 1.10, possibly earlier versions.
- petre 9y ago
  The Go 1.10 release notes mentioned it. That was on 16 feb, which was last thursday. https://golang.org/doc/go1.10#goroot https://golang.org/doc/go1.10#goroot