go – How to structure multi language repository to work reasonably with golang?-ThrowExceptions

Exception or error:

I want to make a library with few language bindings, one of them being golang. It would make sense to have it all in one repository, because for example test data can be shared between them. But I’m not sure how to structure it. I’ve tried is

+   $ tree .
.
└── go
    ├── go.mod
    └── foo.go

1 directory, 2 files

+   $ cat go/go.mod
module github.com/bar/foo/go

go 1.13

+   $ cat go/foo.go
package foo

func Foo() int {
    return 1;
}

Then I tried to use it

+:( $ cat test.go
package main

import (
    "github.com/bar/foo/go"
)

func main() {
    fmt.Println(foo.Foo())
}

But it failed with

+   $ go run ./test.go
go: finding github.com/bar/foo latest
build command-line-arguments: cannot load github.com/bar/foo/go: module github.com/bar/foo@latest (v0.0.0-20191019071519-05aedbdfa600) found, but does not contain package github.com/bar/foo/go

I’m fairly new to golang, so could someone please advice on how are projects like this usually structured?

How to solve:

First of all, in most cases it is a bad idea to name a package after the programming language. What does the package actually DO? Remember, documentation and package layout should be optimized for the user.

For multi-part projects, I personally tend to set up a new organization say foo and create a bar repo for the first part, say the server written in Java, which then would be accessible via https://github.com/foo/bar. Next, for the client written in Go, you set up the next repo baz, which then would be accessible via https://github.com/foo/baz – your go module.

Last, but not least, you can have a „distribution“ repository, which puts the organization‘s projects through a CI pipeline to ensure interoperability.

This approach has multiple advantages, imho: You make it easier for the user to explore the ecosystem, the repos become sufficiently independent while still being tied together by the organization and the individual repos become smaller.

Leave a Reply

Your email address will not be published. Required fields are marked *