Setting up proper Golang directory structure with git to use go build on custom packages

Question

So I've been scratching my head at this for a couple weeks now, and after reading several source on how $ go build works and its three magic directories, /bin, /pkg, /src, it's still not very clear to me how to build Golang projects using custom packages and how a git repo should be managed.

Let me explain my situation in more detail:

I'm working on a Go project in a project directory that is not the same as the default .../user/go/.... For all my projects, I have a different directory tree that is structured like this:

projects
 | project-a
 | project-b
    | docs
    | media
    | scrum
    | project-b   <-- git repo containg Go structure
       | .git
       | gitignore.txt
       | bin
       | pkg
       | src
          | custom-package-a
          |  | foo.go
          | custom-package-b
          |  | bar.go
 |     | main.go      
 | project-c

My projects directory could contain any kind of project: java, Unity3D, VisualC#, etc... then in each project under that it contains a repo with the source code.

I've been able to build successfully recently by adding projects/project-b/project-b to my GOPATH so it sees the src directory.

Is this how the file structure for a typical Go project should look, even though this builds correctly?

In my GOPATH, I removed the original path to user/go and just used the project directory only. When installing other packages from github, they get included in the repo because the GOPATH isn't set anywhere else, so my repo has these different submodules. Is installing external packages into a repo a wise thing to do, or should those go into a different go directory? I'm worried it might muddy the repo.

I can include

I need to know if I'm using custom packages correctly. My intent is to take an object oriented approach with my code base and I'm treating each packages as a class. Is making custom packages to treat them as classes a smart thing to do? I found it necessary to avoid same-name conflicts between functions and variables. Example: package-a.GetThing(), package-b.GetThing(). Both functions yield a similar (not exact) output, but are working with different sets of data and require different implementation.

My console is in projects/project-b/project-b/ when I use go build and it works correctly. Same if I move main.go inside src.

One problem is that the Go builder is strangely placing the compiled binary file in the same directory I invoke go build from. Shouldn't go build be placing it in the bin directory, or do I need to enforce the output path when using the command? I'm aware of GOBIN, but it doesn't seem to be working.

Rudnick

go install is what puts the binary in the bin directory, not go build. Normally you put the project in GOPATH, not vice-versa, I would walk through How to Write Go Code carefully, as any recommendation here would just mirror that. You can of course force whatever pattern you want as you see here (or look into go modules with go1.11, which doesn't need GOPATH) – Nigel

GOPATH is not typically part of the git repository. More typically is if projects/go/src/my.site/project-b/.git and projects/go/src/my.site/project-b/custom-package-a/foo.go exist, the /my.site/ segments being optional. See How to Write Go Code. This will also prevent the "muddying" of the repo with third-party code (unless you want to, of course, in which case it would go into projects/go/src/my.site/project-b/vendor. – Boll

Please read How to Write Go Code and stick to it. – Examination

I assume How to Write Go Code will be updated soon seeing how it does not even mention mod. $GOPATH seems to be on the way out and is a common complaint among users of Go. – Parboil

Answer 1

As of Go 1.11 you don't need to use $GOPATH.

You can use go mod init [your repo] and just run go install or go build The deps will be downloaded for you and a go.mod and go.sum files will be created to track deps.

Check out this README

Parboil