Best practices for keeping a go project inside a larger monorepo?

I'm working on a project that keeps a set of services in a single monolithic repo. Each service has it's own source tree:

.git
services/
    serviceA/
      # A Python project
    serviceB/
      # A Java project

I want to introduce go to this structure. In real life, there is some wiggle room to change the structure itself, but let's for the sake of argument say that this Go service must fit into the existing structure, ie:

.git
services/
    serviceC/
      # Go project can do what it likes here

I've thought of two potential options;

1) simply symlink serviceC into $GOPATH; this seems horrible and likely to cause insane edge cases

2) embed a dedicated $GOPATH structure at serviceC and append that to $GOPATH, ie:

.git
services/
    serviceC/
      bin
      pkg
      src/
        ??/servicec/main.go

This seems less horrible; but I'm concerned the go tool will hiccup on trying to treat first-level directories under src as domains.. and writing a gitignore that excludes everything under src other than my project seems icky..

Suggestions? Are there any writeups of doing this?

Option C: Just go get github.com/foo/yourproject/services/serviceC

This makes for lengthy import paths but maybe you can live with it. If not, set up a vanity alias at your domain.

Digital ocean has a good writeup of this: https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/

You're in production, and it's too early for production, but vgo solves this. It lets you put your code anywhere.

It's from Russ Cox so has a high chance of acceptance, and I've been using it successfully in lightly shared projects at work; it's still a proposal under development, though, do caveat lector.

You don't need to symlink, there's a few options:


goenv

docker, (docker run -it --rm -v $PWD:/go/src/... golang:alpine go build/run/etc.)

have the build toolchain in a docker image (using a CI that you can run locally, like codeship "jet" tool)

Generally, at least docker/CI approach doesn't require you to set up a GOPATH structure, and it's possible to set up vanity aliases so you can have whatever import path you like to your app.

Not sure your comment about src/ is relevant. You would only have your project under src, and for whatever dependencies you pull in, you should be using vendoring by now (dep, recently vgo). Generally it's advised to commit the vendor/ folder, but because of licensing restrictions and such, you might have to pull them on demand (vgo supposedly handles something about licenses something something, didn't read it very carefully, but if you care about which packages you include because of their licenses, you should be using vgo aparently, it's the current thing).