Модули Go заменяют явную версию на v0.0.0- ‹timestamp› - ‹revision› в go.mod

Недавно я добавил в свой проект Go функцию, которая может нарушить работу других проектов, которые ее используют. Я решил поднять основную версию этого проекта, «A», добавив соответствующий тег git 2.0.0 (ранее он был 1.x.x). В другом моем проекте, который требует этого, «B», я обновил его go.mod файл следующим образом:

module gitlab.mydomain.com/namespace/B

go 1.12

require (
    gitlab.mydomain.com/namespace/A v2.0.0
)

Как видите, я специально упомянул v2.0.0, но как только я запускаю B, версия A заменяется на v0.0.0-<timestamp>-<revision>.

Я убедился, что метка существует в пульте.

Что мне здесь не хватает?


person Kludge    schedule 10.12.2019    source источник


Ответы (1)


Начиная с основной версии 2 (v2 и выше), вам необходимо изменить путь импорта, вы должны добавить основную версию в качестве суффикса к пути импорта. Вы должны импортировать пакет как:

import "gitlab.mydomain.com/namespace/A/v2"

И это также должно появиться в go.mod, например:

require gitlab.mydomain.com/namespace/A/v2 v2.0.0

Поскольку основные версии представляют собой несовместимые изменения в Semver, их путь импорта также должен отличаться (один и тот же путь импорта означает одну и ту же зависимость). Это правило совместимости импорта:

Если у старого пакета и нового пакета один и тот же путь импорта,
новый пакет должен быть обратно совместим со старым пакетом.

Подробнее об этом читайте в Go Modules Wiki: почему основные номера версий должны появляться в путях импорта?

А также в сообщении в блоге: Блог Go: Модули Go: v2 и выше

person icza    schedule 10.12.2019
comment
Я начал читать v2 doc - действительно ли нужно делать дополнительную копию всего проекта в _1 _ ..?! - person Kludge; 10.12.2019
comment
@Kludge: нет, для этого просто требуется /v2 в имени модуля и путях импорта. - person JimB; 10.12.2019
comment
@Kludge Это всего лишь одна стратегия управления версиями с точки зрения версионного модуля. Его преимущество заключается в совместимости со старыми системами, не поддерживающими модули. Но это не требование. Если вы используете модули, достаточно простого (совместимого с semver2) тега версии. - person icza; 10.12.2019
comment
@JimB, вот что я сделал и теперь получаю cannot find module providing package gitlab.mydomain.com/namespace/A/v2/somepackage при импорте из B - person Kludge; 10.12.2019
comment
@Kludge Вы переименовали свой модуль в gitlab.mydomain.com/namespace/A/v2? - person icza; 10.12.2019
comment
@icza, Если вы используете модули, достаточно простого (совместимого с semver2) тега версии - как? - person Kludge; 10.12.2019
comment
@Kludge Под этим я подразумеваю, что вы можете просто добавить тег в свой репозиторий с именем v2.0.0, и инструмент go распознает эту точку (фиксацию) для использования, когда вам потребуется v2.0.0. Копия папки v2 (из сообщения в блоге) - это стратегия управления версиями, которая также работает с инструментами, которые не знают модулей. - person icza; 10.12.2019
comment
@icza, но это именно то, что я сделал в первую очередь ... а потом v2.0.0 переопределил на v0.0.0-<timestamp>-<revision> - person Kludge; 10.12.2019
comment
@Kludge: вы уверены, что тоже импортируете /v2? Это поведение go1.12 при попытке импортировать пакет v2.0.0 с исходным путем импорта. Вы пробовали go1.13, который немного более строг в отношении обработки пакетов, что может выявить ошибку? - person JimB; 10.12.2019
comment
@Kludge Как писал JimB: вы должны изменить свой путь импорта так, чтобы он заканчивался vith /v2, иначе инструмент go перепишет требуемый модуль на v0 или v1. - person icza; 10.12.2019
comment
Я уверен насчет /v2, хотя перепроверяю. Тем временем мне удалось обойти это с v2.0.0+incompatible - person Kludge; 10.12.2019
comment
@Kludge А в вашем импортированном пакете (модуле) есть go.mod файл? - person icza; 10.12.2019
comment
@Kludge Было бы очень полезно, если бы вы могли показать нам свои конкретные репозитории, чтобы нам не приходилось спрашивать / угадывать все. - person icza; 10.12.2019
comment
Все еще пытаюсь заставить его работать должным образом. Таким образом, он находит /v2, но не может найти свои подпакеты. Для ясности: я заменил все вхождения импорта на /v2 @icza, @JimB - person Kludge; 11.12.2019
comment
module gitlab.mydomain.com/namespace/A/v2@latest found (v2.0.0, replaced by ../A/v2/), but does not contain package gitlab.mydomain.com/namespace/A/v2/somepackage (я использую replace для локальной работы) - person Kludge; 11.12.2019