Как стать автором
Обновить

Комментарии 12

Да, вы правы. Структура проекта, описанная в https://github.com/golang-standards/project-layout не является стандартом. Обновил на более корректную формулировку.

Можно ли такой трюк делать, если репозиторий находится на большей глубине вложенности?

https://gitlab.com/company/packages/package

Как дать понять адрес репозитория в этом случае?

Вы можете расположить библиотеку в другом месте, все продолжит работать как раньше. Нужно только чтобы:

  • Библиотека была модулем

  • Был git tag, который содержит путь до библиотеки и ее версию

  • Было указано правило replace в go.mod для того, чтобы ваш сервис использовал локальную версию библиотеки

Добавил в своем репозитории пример с библиотекой, которая находится во вложенных директориях. Обратите внимание на тэг для этой библиотеки:

git tag pkg/deep/level1/level2/deeplib/v1.0.0

Теперь ее можно импортировать так:

go get github.com/LopatkinEvgeniy/go-pkg-example/pkg/deep/level1/level2/deeplib@v1.0.0

Твой репозиторий находится на 2 уровне вложенности, поэтому работает. Что если сам репозиторий глубже?

Все должно работать. Во всяком случае этот подход работает в gitlab для проектов, которые находятся в нескольких вложенных группах.

Я проверю, но чисто теоретически - непонятно, как го понимает, что из пути /l1/l2/l3/l4 является путем к репозиторию, а что - путем внутри репозитория

Можно явно указать какая часть пути относится к репозиторию, добавив .git, например `go get long/repo/path.git/inner/pkg/path@v1.0.0`

А если репозиторий с сервисом приватный, как модуль оттуда забирать?

Если вы хотите поделиться библиотеками из приватного репозитория, то лучше рассмотрите другие варианты. Например можно вынести библиотеку в отдельный публичный репозиторий и использовать Go Workspaces при необходимости.

Хранить в одном репозитории несколько модулей, и при этом каждый версионировать своими git tag выглядит как натягивание совы на глобус. git tag ведь накладывается на весь репозиторий, а не на конкретную папку в нём.

Для описанного сценария больше подходит git submodule, в который можно вынести переиспользуемый пакет. Тогда он будет в отдельном репозитории, у него будут только свои теги, а основной репозиторий сможет импортировать его как submodule.

Возможно данный метод выглядит довольно необычным. Однако именно как предлагается делать в документации. Система модулей Golang'а умеет работать с такими тэгами. Это не единственный возможный способ экспортировать модули. Можно попробовать git submodule, как вы описали, можно использовать workspaces. Мне показалось, что описаный в статье способ наиболее удобный.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий