7

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?

John Little
  • 10,707
  • 19
  • 86
  • 158
  • 1
    See [How to Write Go Code](https://golang.org/doc/code.html) for the basics on code organization and workspaces. It sounds like you want multiple workspaces. – Charlie Tumahai Jan 30 '18 at 22:38
  • I have one question...Can you install two PhosoShop of exactly same version in same Windows? Can you install two Visual Studio 2015 in same Windows? Now answer to your quesion...Output of `go build` is a single binary. Place it where ever you want and just execute it as you would execute a nomal program – Nidhin David Jan 31 '18 at 07:42
  • 1
    @NidhinDavid interesting analogy, but coming from a java background we are used to having any number of versions of any library without issue. Trying to get to grips with how go works. We actually do need multiple version of our libraries, the production and dev versions. Constantly switching them is not an option, so just trying to find best way to work. – John Little Feb 01 '18 at 10:24
  • Go is a huge fan of backward compatability. If your library is then there must be no problem for anyone to upgrade..hence no need for version. If not backward compatable then Go recommends a new repository - http://zduck.com/2014/go-and-package-versioning/ BTW I 'am no Go expert..just saying what I heard, thats all. – Nidhin David Feb 01 '18 at 16:55
  • @NidhinDavid You’re mistaking development with executables, especially when projects are huge or you work on multiple projects owned by separate companies intermixing their source is not an appropriate answer. I used Goland and IDE which allows you to set a workspace level `GOPATH`, but this obviously isn’t necessarily the answer to this question. – Ash Dec 17 '18 at 21:48

3 Answers3

5

UPDATE: When I posted this Go did not have modules support and we built and used a tool called vg. These days the recommended way to go is to use go modules.

I use vg for that, it takes care of keeping separate GOPATH paths per project and it switches automatically when you cd a project.

Tommaso Barbugli
  • 11,781
  • 2
  • 42
  • 41
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.

nulldog
  • 39
  • 2
1

With Go 1.11 Go Modules were introduced. You can use Go Modules to have Go projects outside the GOPATH directory.

Here is an example of how to configure a project using GoModules.

LZR
  • 948
  • 10
  • 28