Как структурировать многоязычный репозиторий для разумной работы с golang?

Question

Я хочу создать библиотеку с несколькими языковыми привязками, одна из которых - golang. Было бы целесообразно иметь все это в одном хранилище, потому что, например, тестовые данные могут быть разделены между ними. Но я не уверен, как это структурировать. Я пробовал

+   $ 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;
}

Затем я попытался использовать его

+:( $ cat test.go
package main

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

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

Но это не удалось с

+   $ 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

Я довольно новичок в Голанге,Может, кто-нибудь посоветует, как такие проекты обычно структурированы?

Answer 1

Прежде всего, в большинстве случаев плохая идея называть пакет в честь языка программирования. Что на самом деле делает пакет? Помните, что документация и макет пакета должны быть оптимизированы для пользователя.

Для проектов, состоящих из нескольких частей, я лично стремлюсь создать новую организацию, скажем foo, и создать репо bar для первой части,скажем, сервер, написанный на Java, который затем будет доступен через https://github.com/foo/bar. Далее, для клиента, написанного на Go, вы устанавливаете следующую базу репо, которая затем будет доступна через https://github.com/foo/baz - вашgo module.

И последнее, но не менее важное: у вас может быть «распределительный» репозиторий, который направляет проекты организации через конвейер CI для обеспечения взаимодействия.

Этот подход имеет несколько преимуществ, imho: Пользователю становится проще исследовать экосистему, репо становятся достаточно независимыми, но все еще связаны организацией, а отдельные репо становятся меньше.