Мы конвертируем нашу внутреннюю кодовую базу из менеджера зависимостей dep в модули go (vgo или встроенные в go1.11.2).Представьте, что у нас есть такой код:
$ GOPATH / src / mycompany / myprogram / main.go:
package main
import (
"fmt"
lib "mycompany/mylib" )
func main() {
fmt.Println("2+3=", lib.add(2, 3))
}
$ GOPATH / src / mycompany/myprogram/go.mod:
module mycompany/myprogram
(не имеет никаких зависимостей; наш реальный код имеет).
$ GOPATH / src /mycompany / mylib / lib.go:
package mylib
func Add(x int, y int) int {
return x + y
}
Я не модулировал этот код;Кажется, не имеет значения, делаю я это или нет.
Это тривиальные примеры, но наш внутренний код следует той же структуре, что и исторически.
Поскольку эти каталоги находятся наGopath, export GO111MODULE=auto по-прежнему строит как и раньше, и это прекрасно работает (модули не используются, потому что мы находимся на Gopath).Однако, когда я установил export GO111MODULE=on, я сразу же получил ошибку:
build mycompany/myprogram: cannot find module for path mycompany/mylib
Поэтому я провел небольшое исследование и хотел бы подтвердить свое понимание.Прежде всего позвольте мне сказать, что наш старый подход сработал, но меня больше интересует изменение использования модулей go, поскольку, как представляется, именно туда движется сам проект go.Итак.
Кажется, целью авторов golang было то, что пути без точек принадлежат только стандартному репозиторию;то есть должна быть привязка между доменным именем и проектом.Не удивительно, что мы не используем go get для нашего внутреннего проекта. Вот источник , в частности:
Пути без точек в общем случае зарезервированы для стандартной библиотеки;go get имеет (насколько мне известно) никогда не работал с ними, но go get также является основной отправной точкой для работы с версионными модулями.
Может ли кто-нибудь с большим знанием Голанга, чем я, подтвердить это?
Мое ключевое предположение заключается в том, что как только go решит использовать модули, все зависимости должны быть модулями, и gopath становится несколько неактуальным, кроме каккеш (для загружаемых модулей).Это правильно?
Если это правда, нам нужно использовать частный репозиторий gitlab (в нашем случае) на пути. Существует открытая проблема с этим, я знаю о , поэтому мы можем реализовать это при необходимости.Меня больше интересуют последствия, особенно для итерации в частных репозиториях.Ранее мы могли разрабатывать эти библиотеки локально, прежде чем вносить какие-либо изменения;теперь кажется, что у нас есть выбор:
- Примите эту удаленную зависимость и повторите.Я надеялся избежать необходимости толкать и тянуть дистанционно, как это.Существуют обходные пути для необходимости подключения к Интернету, если это строго необходимо.
- Объедините все в один большой git-репозиторий.
Если это имеет значение, я использую go version go1.11.2 linux/amd64 и мои коллеги используют darwin/amd64.Если это помогает, мой golang точно такой же, как установлен репозиториями Fedora.
Итак, tl;dr, мой вопрос: все ли модули go или all, что любая зависимость должна быть разрешена с использованием системы модулей(иди, похоже), а гопат стал лишним?Или в моей настройке есть что-то, что может привести к сбою?Есть ли какой-то способ указать, что зависимость должна быть разрешена явно из gopath?
Обновления после того, как задан вопрос :
- Я могу переместить
myprogram изгопата.Возникает та же проблема (mylib было оставлено в gopath). - Я могу запускать или не запускать
go mod init mycompany/mylib в каталоге mylib;это не имеет никакого значения. - Я наткнулся на сообщение в блоге Расса Кокса на vgo .Мои опасения по поводу офлайн-разработки, в которые я старался не вдаваться слишком далеко, разрешились
$GOPROXY.