Как заставить модули Go семантический импорт версий v2 + работать с путем импорта тщеславия

Мы пытаемся перенести нашу базу кода Go в модули go, и я не могу понять, как заставить ее работать с путями импорта тщеславия.


С dep

До сих пор наш инструмент управления зависимостями был dep. Мы поместим файл Gopkg.toml в корень нашего проекта и определим зависимость, например:

[[constraint]]
  name = "mycompany.com/some-lib"
  version = "3.0.0"

Как видите, мы используем так называемый путь тщательного импорта для наших собственных пакетов. Фактически, наш код вообще размещен на частном сервере git.
Итак, вместе с этим мы настроили еще один сервер, который отображает метатеги HTML с информацией репозитория. Например.:

<meta 
    name="go-import" 
    content="mycompany.com/some-lib git https://mygitserver.com/some-lib"
>

Этот механизм в основном описан в документации cmd / go, Пути удаленного импорта.


С модулями go

Таким образом, вместо модулей go у меня есть export GO111MODULE=on и go.mod файл, который требует зависимости в соответствии с управление версиями семантического импорта:

module foo

go 1.13

require (
    mycompany.com/some-lib/v3 v3.0.0
)

Обратите внимание, что путь импорта имеет суффикс v3, как того требует управление версиями семантического импорта. И проект some-lib также имеет свой собственный go.mod файл, который начинается с: module mycompany.com/some-lib/v3.

Теперь моя проблема в том, что когда go get или go build разрешение зависимости не выполняется с:
go: mycompany.com/some-lib/[email protected]: unrecognized import path "mycompany.com/some-lib/v3" (parse https://mycompany.com/some-lib/v3?go-get=1: no go-import meta tags ())

Конечно, это происходит, потому что мой удаленный сервер импорта обрабатывает mycompany.com/some-lib, но не mycompany.com/some-lib/v3.


Вопрос

  • Разве команда go не может автоматически обрабатывать импорт с контролем версий? Я думал, что он запросит mycompany.com/some-lib, а затем сам получит v3.
  • Должен ли я обрабатывать каждый /vN маршрут на моем удаленном сервере импорта?
  • Если да, что писать в теге <meta>? Если нет, что мне делать?

Дополнительная информация: я видел некоторые документы и статьи, в которых рекомендуется дублировать код в каталогах, названных в честь основных версий, например:

/               ---> contains v1.x.y code
|_ main.go
|_ interface.go
|_ go.mod
|_ /v2          ---> contains v2.x.y code
    |_ main.go
    |_ interface.go
    |_ go.mod

Или, как вариант, поддерживать отдельные ветки для каждой основной версии.
Я не хочу этого делать. И я хочу require mycompany.com/some-lib/v3 v3.0.0 или require mycompany.com/some-lib/v4 v4.1.0 в зависимости от потребностей каждого клиентского проекта и получать версии из того же места, как и в случае с dep.

Дополнительная информация 2: как ни странно, ВСЕ сторонние зависимости нашего проекта либо не являются модулями, либо все еще находятся в версиях v0 или v1, либо просто размещены на github, поэтому я не могу найти подходящие примеры.

Любое понимание чрезвычайно ценится. Спасибо.


person blackgreen    schedule 12.09.2019    source источник


Ответы (1)


Должен ли я обрабатывать каждый /vN маршрут на моем удаленном сервере импорта?

да. (Вы уже должны обрабатывать каждый путь, который может соответствовать пакету в репозитории: см. https://golang.org/cmd/go/#hdr-Remote_import_paths.)

Если да, что писать в теге <meta>?

Точно то же самое, что вы пишете сегодня, должно работать: одни и те же пути, без суффикса /vN, если вы не хотите направлять разные версии в разные репозитории.

person bcmills    schedule 13.09.2019