Модули Голанга, частные репозитории и гопаты

Question

Мы конвертируем нашу внутреннюю кодовую базу из dep менеджер зависимостей для перехода модулей (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. Так.

1. Похоже, авторы golang намеревались сделать так, чтобы пути без точек принадлежали только стандартному хранилищу; то есть должна быть привязка между доменным именем и проектом. Не удивительно, что мы не используем go get для нашего внутреннего проекта. Вот источник конкретно:

   Пути без точек в общем случае зарезервированы для стандартной библиотеки; go get уже (насколько мне известно) никогда не работал с ними, но go get также является основной отправной точкой для работы с версионными модулями.

   Может ли кто-нибудь с большим знанием Голанга, чем я, подтвердить это?

2. Мое ключевое предположение заключается в том, что, как только go решит использовать модули, все зависимости должны быть модулями, и gopath становится несколько неактуальным, кроме как кеш (для загруженных модулей). Это правильно?

3. Если это правда, нам нужно использовать частный репозиторий gitlab (в нашем случае) на пути. Мне известно об этой проблеме, и мы можем реализовать ее при необходимости. Меня больше интересуют последствия, особенно для итерации в частных репозиториях. Ранее мы могли разрабатывать эти библиотеки локально, прежде чем вносить какие-либо изменения; теперь кажется у нас есть выбор:

   1. Примите эту удаленную зависимость и повторите. Я надеялся избежать необходимости толкать и тянуть дистанционно, как это. Есть обходные пути для необходимости подключения к Интернету, если это строго необходимо.
   2. Объедините все в один большой Git-репозиторий.

Если это имеет значение, я использую go version go1.11.2 linux/amd64 и мои коллеги используют darwin/amd64, Если это поможет, мой golang точно такой же, как установлен репозиториями Fedora.

Так, tl;drмой вопрос: все ли модули go или all, что любая зависимость должна быть разрешена с использованием системы модулей (похоже, go get) и gopath стал избыточным? Или в моей настройке есть что-то, что может привести к сбою? Есть ли способ указать, что зависимость должна быть разрешена явно из gopath?

Обновления с момента постановки вопроса:

1. Я могу двигаться myprogram из гопата. Такая же проблема возникает (mylib был оставлен в гопате).
2. Я могу бежать или не бежать, go mod init mycompany/mylib в каталоге mylib; это не имеет значения вообще.
3. Я наткнулся на сообщение в блоге Расса Кокса на VGO. Мои опасения по поводу офлайн-разработки, в которые я старался не вдаваться, решаются $GOPROXY,

Answer 1

Я использую обходной путь с GITHUB_TOKEN, чтобы решить эту проблему.

1. Сгенерируйте GITHUB TOKEN здесь https://github.com/settings/tokens
2. export GITHUB_TOKEN=xxx
3. git config --global url."https://${GITHUB_TOKEN}:[e-mail]/mycompany".insteadOf "https://github.com/mycompany"
4. Прибыль!

Answer 2

Я использую команду ls-remote git, чтобы разрешить частные теги репо и перейти к ним.

$ go env GO111MODULE=on
$ go env GOPRIVATE=yourprivaterepo.com
$ git ls-remote -q https://yourprivaterepo.com/yourproject.git
$ go get

Answer 3

Я написал решение для этого на Medium: Go модули с частными репозиториями Git.

То, как мы справляемся с этим, в основном совпадает с ответом выше от Алекса Плитау, и в блоге более подробно рассматриваются примеры того, как настроить ваш git config с токенами из GitHub/GitLab/BitBucket.

Соответствующий бит для GitLab:

git config --global \
  url."https://oauth2:${personal_access_token}@privategitlab.com".insteadOf \
  "https://privategitlab.com"

#or 

git config --global \
  url."https://${user}:${personal_access_token}@privategitlab.com".insteadOf \
  "https://privategitlab.com"

Я надеюсь, что это полезно.