使用模块时，Go get找不到本地包

Go get cannot find local packages when using modules

我对Go的新模块系统有问题，因为我想定义一个本地模块并将其导入主程序。本地包位于主包/根文件夹的文件夹中。想象一下在$GOPATH之外的以下项目结构。

项目结构

去。

1
2
3
4
5
6
7
8
9
10

package main

import"fmt"
import"example.com/localModule/model"

func main() {
var p = model.Person{name:"Dieter", age:25}
fmt.Printf("Hello %s
", p.name)
}

/型号/人.go

1
2
3
4
5
6

package model

type Person struct {
name string
age int
}

在根文件夹中，我通过调用

1	go mod init example.com/localModule

在model/文件夹中，然后通过调用

1	go mod init example.com/localModule/model

误差

在根文件夹中调用以下命令失败。

1
2
3
4
5

$ go get
go build example.com/localModule/model: no Go files in

$ go build
main.go:4:8: unknown import path"example.com/localModule/model": cannot find module providing package example.com/localModule/model

Go-Get的错误消息被切断了，我不能错误地解析它。

我不打算把模块推到服务器上，只需要一种引用本地包model的方法，所以我分别选择了example.com/localModule/和example.com/localModule/model。

我在运行MacOS 10.13.6的MacBook上使用go1.11 darwin/amd64。

通过在go.mod中添加一个require语句和一个匹配的replace语句以及一个相对文件路径，可以像您要求的那样拥有本地"sub"模块。

在"root."/go.mod中：

1
2
3
4
5

module example.com/localModule

require example.com/localModule/model v0.0.0

replace example.com/localModule/model v0.0.0 => ./model

相关讨论

出现此错误的原因是您定义了两个不知道如何在本地磁盘上找到彼此的模块。

1
2
3

$ go build
main.go:4:8: unknown import path"example.com/localModule/model":
cannot find module providing package example.com/localModule/model

虽然可以使用replace指令让一个模块在磁盘上找到另一个模块，但更常见和简单的解决方案是：

在您的存储库中有一个单独的go.mod文件，并且
将单个go.mod文件放在存储库的根目录中。

这是一个非常简单的解决方案，这意味着存储库中的两个包将能够找到彼此，从而避免了您报告的错误消息，也避免了在这里需要一个replace指令。

Russ Cox在26664年评论道：

For all but power users, you probably want to adopt the usual convention that one repo = one module. It's important for long-term evolution of code storage options that a repo can contain multiple modules, but it's almost certainly not something you want to do by default.

如果您希望在单个存储库中定义多个模块，那么关于如何正确地定义多个模块有相当多的细微差别，并且在模块wiki中有一个完整的部分，介绍如何管理与单个存储库中多个模块相关联的复杂性，包括以下建议：

Adding modules, removing modules, and versioning modules with multiple modules in a single repository requires considerable care and deliberation, so it is almost always easier and simpler to manage a single-module repository rather than multiple modules in an existing repository.

和

Please read all of the FAQs in this sub-section carefully if you are considering having multiple modules in a single repository.