mirrr
@mirrr
Программист и просто хороший человек

Как организовать структуру подпакетов проекта?

Существует крупный проект с большим количеством файлов, которых уже слишком много в корневом каталоге. К тому-же было бы неплохо отделить мух от котлет, контроллеры от моделей и т.д., вынести их в отдельный каталог. Но есть "но".

Go предоставляет возможность создавать подпакеты, с двумя сособами их импорта.

Импорт с относительными путями:
import "./sub-package"

Go-сообществом считается плохой идеей, к тому же не работает, если проект находится в каталоге $GOPATH.

Импорт с указанием родительского пакета
import "github.com/user/main-package/sub-package"

Чаще всего это наилучший способ, но проекты фирмы находятся не на github, а в закрытом репозитории, который не поддерживает go get, а админы при деплое могут склонировать репозиторий не только в $GOPATH/src, но и в $GOPATH/src/CompanyApps или вообще в /srv. В таком случае import "package/subpackage" сломается. Не говоря уже о том, что в конторе десяток разрабов и в какую папку склонируют пакет к себе можно узнать только по крикам, что проект не собирается.

UPD: Вторая ситуация - при форке такого проекта все секции import указывают на подпакеты оригинального проекта, изменения в котором могут сломать форк.

Хотелось бы услышать оптимальный способ решения таких задач.
  • Вопрос задан
  • 666 просмотров
Решения вопроса 1
@IllusionTurtle
не совсем понимаю суть проблемы.

для крупных проектов использую директорию vendor, причем код разрабатываемого приложения тамже, пример:
GOPATH = ~/go
~/go/src/.../PROJECT/vendor/projectName/
~/go/src/.../PROJECT/vendor/projectName/projectName.go - package main
~/go/src/.../PROJECT/vendor/projectName/controllers/
~/go/src/.../PROJECT/vendor/projectName/models/
~/go/src/.../PROJECT/vendor/projectName/templates/
...
~/go/src/.../PROJECT/vendor/someutil/
~/go/src/.../PROJECT/vendor/github.com/user/package/
~/go/src/.../PROJECT/assets/
~/go/src/.../PROJECT/testdata/
~/go/src/.../PROJECT/ - тут лежат бинарники, конфиг файлы, Makefile ит.д.

подобная структура позволяет иметь в проекте "красивые" пути к внутренним компонентам проекта - контролерам, моделям ит.д.
позволяет иметь локальные версии каких-то внешних пакетов
и в тоже самое время позволяет импортировать внешние пакеты не перенося их в директорию vendor
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
uvelichitel
@uvelichitel Куратор тега Go
habrahabr.ru/users/uvelichitel
  • С закрытыми репо не умеет 'go get'. После клонирования в нужное место '$GOPARH/src/package/subpackage' посредством git (или rsync) команды 'go build', 'go install', 'go run' работают как ни в чем не бывало. import "package/subpackage"
  • GOPATH - это лист так же как и PATH, перечень список возможно нескольких путей. Валидно export GOPATH=$GOPATH:"/srv"
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы