3 ms·

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

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.

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.