将Go项目与其他非Go项目一起存储

Question

When it comes to code organization, Go seem to make an assumption, that it's the only language I'm going to use. However, I'd like to treat each Go project as a yet another isolated piece of software, and store it the same way as most programs were stored for decades now - in an arbitrary directory, containing no less and no more than what is needed to build and run it.

What Go wants:

home/
├─go/
│ └─src/
│   └─some-organization/
│     └─some-go-project/
│       └─main.go
└─projects/
  └─some-organization/
    ├─some-c-project/
    │ └─src/
    │   └─main.c
    └─some-python-project/
      └─src/
        └─main.py

What I want:

home/
└─projects/
  └─some-organization/
    ├─some-c-project/
    │ └─src/
    │   └─main.c
    ├─some-python-project/
    │ └─src/
    │   └─main.py
    └─some-go-project/
      └─src/
        └─main.go

Of course, nobody prevents me from structuring it my way, but I won't be able to build/install that project the intended way anymore. Doing something like home/projects/some-organization/some-go-project/src/some-go-project/main.go to address that is just too ugly to my liking.

So what's the consensus here? How does Go community handle this? Back-to-make?

Answer 1

I had the same problem, and tried the following solutions (in chronological order):

• don't put you package in the $GOPATH and compile from your project directory: that works while you have a single-package project. Anyway, go project should have a limited number of package…
• use a symlink from your project directory to your $GOPATH: it's really boring to have to symlink everytime you want to checkout a new project. More, the various tools asking for a package name (fmt, test, etc) won't find your package, unless you make the link the other way around, which is equally boring (even more, as it defies your git layout).
• add a $GOPATH entry for each project (like $PATH): even more boring than the previous solution, but mostly works. Even better if your poject layout is based on a src/ directory.
• use vagrant and a dedicated $GOPATH: you can work as intended by golang, with the added complexity of having to ssh into the box. That's what I am doing now, as it have the benefits of vagrant as a bonus.