Как построить golang проектов, чьи зависимости зависят от другой версии зависимости проекта - PullRequest
Новая
       61

Как построить golang проектов, чьи зависимости зависят от другой версии зависимости проекта

0 голосов
/ 11 апреля 2020

Представьте, что у вас есть проект, который требует двух модулей A и B. Я назову модуль проекта P. Допустим, для P требуется A v1.0.0, B v1.1.0, а для A требуется B v1.0.0. Более того, B не придерживался правил управления версиями semanti c, поэтому изменение версии с v1.0.0 -> v1.1.0 привело к нарушению API. Так что P строит только с v1.1.0 и A строит только с v1.0.0.

График зависимостей: 

P -> A (v1.0.0) -> B(v1.0.0)
P -> B (v1.1.0)

Есть ли способ построить этот проект с разными версиями , Я слышал о vendoring , но я не уверен, приведет ли это к зависимости, чтобы использовать другую версию модуля B.

И если это могло бы обеспечить решение для конфликтующих версий пакета , распознает ли инструмент go модули, использующие вендор, если в зависимости не входит папка вендора (некоторые люди говорят, что вы не должны загружать папку вендора) в их хранилище git (В этом случае модуль A не поставляется с папкой vendor, но разработчик по имени go mod vendor локально), команда go get уважает папки зависимостей vendor (или он может обнаружить, что модуль использовал vendoring без восходящей папки vendor)?

1 Ответ

2 голосов
/ 11 апреля 2020

Это похоже на конфликт, который система модуля не может разрешить. Поскольку Go использует управление версиями semanti c, он попытается получить B v1.1.0 для разрешения обеих зависимостей, а затем сборка прекратится, если A не сможет работать с B 1.1.0.

Лучший способ разрешить это исправить B, не нарушая API в неосновной версии.

Не имея этого, вы могли бы fork B в отдельный модуль (с именем модуля, отличным от исходного B ) и используйте старую версию в A. Создайте BFORK=Bv1.0.0, и тогда у вас будет: 

P -> B (v1.0.0)
A -> BFORK vX.X.X
...