如何管理多个项目目录的GOPATH

Question

coming from a java and grails background, (and having written millions of lines of C 30 years ago), I cant see how go can be usable with a fixed gopath on windows.

installing go creates this structure

c:\users\me\go\scr
              \pkg
              \bin

As you will want to have many go projects it seems they have to be mixed together in the same src/kpg/bin dirs, polluting each other. e.g.

/src/project1/hello.go
    /project2/hello.go
/pkg/xx
/bin/hello.exe

Which hello.go will hello.exe run?

Unless I am missing something fundamental, this seems crazy - all completely separate projects are expected to share the same package and bin dirs. It means you dont know which versions of which packages, and which exe files belong to which project, and there is presumably plenty of scope for conflicts. I would have expected a /src, /pkg and /bin for each separate go app (like java or grails or even C), and go path is completely redundant, it can be relative to the current project root (like in grails).

To make matters works, for work, we have to use a different directry, e.g.

d:\work\project3
       \project4
       \package5
           \go_utility6
           \go_utility7

So now we have a total of 6 separate directories where go progams live. It is not feasible to change the path every time you switch to working on a different project. I guess the other option is to add the 6 paths to the GOPATH. Presumably, all 7 go projects write to the same pkg and bin dir, which is going to be a disaster.

Is there a tenable solution to this situation (on windows at least)?

If we need to add a PATH to GOPATH for every project, what should the file structure be under each project?

E.g. uner xxx\go_utility6, which is a stand alone command line go app, what should the structure be? does there need to be a src dir in there somewhere? does this dir need gopath to point to it? does it need its own pkg, or should it use the c:\users\me\pkg dir?

Answer 1

Your example "which hello.exe" should be used honestly makes not much sense. Two tools with the same name? Even if both are, let's say, an api, your devops will be happier with more meaningful names.

The bin folder is used for 3rd party tools you install, you so not have to install your project binaries. Except they are tools, but then the name should be meaningful again.

You can get more information about the project structure here: https://golang.org/doc/code.html

Since go 1.8 supports a vendor folder below project folders, it is possible to break the original structure. (imho vendors were not maintainable before 1.8, yes that was crazy)

You might want to use a tool like direnv, which would support your desire to change GOPATH per project. https://github.com/direnv/direnv

It also has some built in function for adding the current path to the GOPATH. https://github.com/direnv/direnv/blob/master/stdlib.sh#L355:1

For example GoLang also supports handling multiple GOPATHs and per project GOPATHs. So direnv should also work properly.

In my company we have one go folder right next to our other projects. Under go/src are our projects. No problem so far, since vendors are in the projects' vendor folders and committed.

The so far best dependency manager I would recommend for go is: https://github.com/golang/dep

I hope that input helps.