Иерархия продавцов

Мой проект го состоит из множества компонентов. У каждого компонента есть собственный каталог поставщиков, который заполняется файлом dep. Поскольку компоненты имеют похожие зависимости, существует огромное дублирование в каталогах поставщиков. Вдобавок поставщики довольно большие: ~ 20 МБ.
Моя идея состоит в том, чтобы уменьшить размер репозитория, указав общего поставщика в верхней части проекта. project vendor |--component1 |----main.go |----vendor |--component2 |----main.go |----vendor

Каждый компонент должен определять только специфические для него зависимости. Чтобы не предоставлять общие зависимости для каждого dep ensure, выполняемого на уровне компонента, мы можем указать, какие пакеты следует игнорировать в файле Gopkg.toml:

ignored = ["github.com/aszecowka/calc"]

Вопрос: кто-нибудь использует такой подход? Есть альтернативы?

Обновление. Контекст: в моей компании мы изучаем подход монорепозитория, мы пытаемся объединить разные проекты go, но в итоге получаем действительно огромный репозиторий - в основном из-за каталогов многих поставщиков.


go vendor godeps
person Adam Szecowka    schedule 29.06.2018    source источник
comment
Все используют этот подход, потому что несколько каталогов поставщиков вызывают конфликты типов.. В каждом основном пакете должен быть только один каталог поставщика. Другими словами, у component1 и component2 не должно быть каталога поставщика. Основной пакет должен собрать набор поставляемых пакетов, который работает со всеми его зависимостями.   -  person Peter    schedule 29.06.2018
comment
Возможно, вам следует использовать так называемое выравнивание зависимостей, то есть у вас есть единственный каталог vendor верхнего уровня и все зависимости, включая переходные, там. См. это.   -  person kostix    schedule 29.06.2018
comment
@kostix Мои компоненты разрабатываются отдельными командами. Все компоненты зависят от k8s, но также включают разные домены. Я не хочу иметь одного продавца, потому что он станет огромным. Кроме того, для компонента 1 может потребоваться такая же зависимость, что и для компонента 2, но в другой версии.   -  person Adam Szecowka    schedule 29.06.2018
comment
@Peter спасибо за ваш ответ. В моем примере component1 и component2 - это отдельные приложения, у обоих есть main.go файл (я обновил описание моей проблемы) и собственные поставщики. Мой вопрос: если оба компонента используют некоторые общие библиотеки, можем ли мы извлечь эти перекрывающиеся зависимости и поместить их в каталог поставщика на уровне выше? В моей компании мы изучаем подход монорепозитория, мы пытаемся объединить различные проекты go, но в итоге получаем действительно огромный репозиторий - в основном из-за множества каталогов поставщиков.   -  person Adam Szecowka    schedule 29.06.2018
comment
@AdamSzecowka нет, по той же причине, что и Питер: в каждом основном пакете должен быть только один каталог поставщика.   -  person Adrian    schedule 29.06.2018
comment
По-настоящему интересное обсуждение можно найти здесь: github.com/golang/dep/issues/985 да, сглаживание каталогов поставщиков до единственного, самого верхнего уровня является основополагающим в дизайне dep. вложенные каталоги поставщиков могут вызвать множество проблем, и их удаление было сделано намеренно. изменить этот дизайн - это не то, что мы можем сделать. И: dep не предназначен в первую очередь для использования в монорепозиториях прямо сейчас   -  person Adam Szecowka    schedule 30.06.2018