Go模块，私有仓库和gopath [英] Go modules, private repos and gopath

问题描述

我们正在将内部代码库从dep依赖关系管理器转换为go模块(vgo或内置于go1.11.2中).假设我们有这样的代码:

We are converting our internal codebase from the dep dependency manager to go modules (vgo or built in with go1.11.2). Imagine we have code like this:

$ 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

(它没有任何依赖关系；我们的实际代码中有).

(it doesn't have any dependencies; our real-world code does).

$ GOPATH/src/mycompany/mylib/lib.go:

package mylib

func Add(x int, y int) int {
        return x + y
}

我没有对该代码进行模块化；不管我是否做都不重要.

I didn't module-ize this code; it doesn't seem to matter whether I do or don't.

这些是简单的示例，但是我们的内部代码遵循与历史上类似的结构.

These are trivial examples but our internal code follows a similar structure as this worked historically.

由于这些目录位于Gopath上，因此export GO111MODULE=auto仍可以像以前一样构建并且可以正常工作(未使用模块，因为我们位于gopath上).但是，当我设置export GO111MODULE=on时，我立即收到错误消息:

Since these directories are on the Gopath, export GO111MODULE=auto still builds as before and this works fine (modules not used because we are on the gopath). However, when I set export GO111MODULE=on I immediately get the error:

build mycompany/myprogram: cannot find module for path mycompany/mylib

所以我做了一些研究，我想证实我的理解.首先，让我说我们的旧方法可行，但是我对更改使用go模块更感兴趣，因为它似乎是go项目本身的目标所在.是这样.

So I did some research and I would like to validate my understanding. First let me say our old approach worked, but I am more interested in changing to use go modules as it appears to be where the go project itself is headed. So.

1. golang作者的意图似乎是无点"路径仅属于标准存储库；域名和项目之间应该有绑定.毫不奇怪，我们不会在我们的内部项目中使用go get. 此处为来源:

通常，无点路径是为标准库保留的； (据我所知)go get从未与他们合作，但是go get也是使用版本化模块的主要切入点.

Dotless paths in general are reserved for the standard library; go get has (to my knowledge) never worked with them, but go get is also the main entry point for working with versioned modules.

除了我以外，对golang的了解还多的人可以确认吗?

Can anyone with more knowledge of golang than me confirm this?

我的主要假设是，一旦go决定使用模块，所有依赖项必须是模块，并且gopath变得无关紧要，除了作为缓存(对于下载的模块).这是正确的吗?

My key assumption is that once go decides to use modules, all dependencies must be modules and the gopath becomes somewhat irrelevant, except as a cache (for downloaded modules). Is this correct?

如果为真，则需要在路径上使用私有gitlab(在我们的情况下)存储库. 在我所知的处理方法上有一个未解决的问题，因此，如果必要的.我对后果更感兴趣，特别是对于在私有存储库中进行迭代.以前，我们可以在提交任何更改之前在本地开发这些库.现在看来我们可以选择:

If this is true, we need to use a private gitlab (in our case) repository on the path. There's an open issue on handling this that I'm aware of so we can implement this if necessary. I'm more interested in the consequences, specifically for iterating in the private repositories. Previously we could develop these libraries locally before committing any changes; now it seems we have a choice:

1. 接受此远程依赖关系并进行迭代.我希望避免像这样进行远程推拉.如果确实有必要，有一些变通方法需要互联网连接.
2. 将所有内容合并到一个大的git存储库中.

如果有关系，我正在使用go version go1.11.2 linux/amd64，而我的同事正在使用darwin/amd64.如果有帮助，我的golang完全与Fedora的存储库中安装的一样.

If it matters, I'm using go version go1.11.2 linux/amd64 and my colleagues are using darwin/amd64. If it helps, my golang is exactly as installed by Fedora's repositories.

所以，tl;dr，我的问题是:go模块是全有还是全无，因为任何依赖都必须使用模块系统来解决(看起来是get)，并且gopath变得多余了?还是有关我的设置的某些信息可能触发此操作失败?有什么方法表明应该从gopath中显式解决依赖关系吗?

So, tl;dr, my question is: are go modules all-or-nothing, in that any dependency must be resolved using the module system (go get, it seems) and the gopath has become redundant? Or is there something about my setup that might trigger this to fail? Is there some way to indicate a dependency should be resolved explicitly from the gopath?

自提出问题以来进行更新:

1. 我可以将myprogram移出gopath.发生相同的问题(mylib已留在gopath中).
2. 我可以在mylib目录中运行或不运行go mod init mycompany/mylib；完全没有区别.
3. 我遇到了 Russ Cox关于vgo的博客文章. $GOPROXY解决了我对脱机开发的担忧，我试图避免深入探讨.

1. I can move myprogram out of the gopath. The same issue occurs (mylib has been left in the gopath).
2. I can run, or not run, go mod init mycompany/mylib in the mylib directory; it makes no difference at all.
3. I came across Russ Cox's blog post on vgo. My concerns about offline development that I tried not to dive into too far are resolved by $GOPROXY.

推荐答案

我对GITHUB_TOKEN使用解决方法来解决此问题.

I use a workaround with GITHUB_TOKEN to solve this.

1. 在此处 https://github.com/settings/tokens
生成GITHUB_TOKEN
2. export GITHUB_TOKEN=xxx
3. git config --global url."https://${GITHUB_TOKEN}:[e-mail]/mycompany".insteadOf "https://github.com/mycompany"

1. Generate GITHUB_TOKEN here 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"

这篇关于Go模块，私有仓库和gopath的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！