Мы пытаемся перенести нашу базу кода 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, поэтому я не могу найти подходящие примеры.
Любое понимание чрезвычайно ценится. Спасибо.