【问题标题】:go modules multiple main methodsgo modules 多个主要方法
【发布时间】:2019-07-04 22:17:12
【问题描述】:

我有一个包含多个主要方法的项目。 当运行具有与program2/main2.go 不同的依赖集的go build program1/main1.go 时,我的第一个go build 似乎改变了我的go.mod 文件并删除了它认为它不需要的依赖关系。然而main2 需要这些依赖项。

我尝试过使用go build ...,但这也创建了一组不同的依赖项。具体来说,似乎所有 //indirect 依赖项都被删除并导致 program2 失败。

有没有办法在不更新go.mod 文件的情况下运行go buildgo run?使用go build -mod=readonly program1/main1.go 它告诉我它失败了,因为需要更新依赖项..

【问题讨论】:

  • 如果两件事具有相同的依赖关系,并且每个都应该有自己的go.mod。 go.mod 包含 依赖项,而不仅仅是 some(读取“不相关”、“旧”和“copy-past-leftovers”)依赖项。

标签: go go-modules


【解决方案1】:

我相信您正在寻找子模块。见this walktrhough

TLDR:您需要在每个工具的 cmd 目录中都有一个单独的 go.mod,并且您可以使用 replace 指令将这些工具的依赖项指向您的本地模块。

This Go Issue 和其他链接的人建议找出“一种正确的方法”来做到这一点仍然是 WIP,尽管我认为你的用例很简单。

【讨论】:

  • 是的,最终我就是这样做的 :) 谢谢!
【解决方案2】:

使用子模块是一种嵌套多个 Go 模块项目的方法,您可以编辑

但 Go 1.18 可能包含 Go 工作区 的概念,这意味着您不再需要子模块:一个Go 项目可以包含多个您可以编辑的模块。

参见golang/go issue 45713: "proposal: cmd/go: add a workspace mode " 及其design document

背景

用户通常希望跨多个模块进行更改:例如,在一个模块的包中引入新接口,同时在另一个模块中使用该接口。

通常,go 命令识别用户可以编辑的单个“main”模块。
其他模块是只读的,从模块缓存中加载。

go mod replace 指令是个例外:它允许用户用磁盘上的工作版本替换模块的解析版本。
但是使用replace 指令通常会很尴尬:每个模块开发人员可能在磁盘上的不同位置都有工作版本,因此将指令放在需要与模块一起分发的文件中并不适合所有人使用案例。

提案

此提案在go 命令中描述了一种用于编辑多个模块的新工作区模式。

工作目录或包含目录中存在 go.work 文件会将go 命令置于工作区模式
go.work 文件指定了一组组成工作空间的本地模块。在工作区模式下调用时,go 命令将始终选择这些模块和一组一致的依赖项。

主要模块:用户正在使用的模块。
在此提议之前,这是包含调用go 命令的目录的单个模块。此模块用作运行 MVS 时的起点。
此提案提出允许多个主模块

例如参见CL 334934(CL = 更改列表)

[dev.cmdgo] cmd/go:添加工作区模式

此更改添加了工作区模式的实现大纲。

go 命令现在将定位 go.work 文件,并读取它们以确定 工作区中有哪些模块。
然后,它会在构建构建列表时将这些模块放在工作区的根目录中。
它支持在工作区中构建、运行、测试和列出。

您可以使用go mod initwork 启动一个多模块项目

同样,这不是在 Go 1.18(2022 年第一季度)之前,并且可能会选择加入 Go 1.19(2022 年第三季度)。

【讨论】:

    猜你喜欢
    • 2017-02-21
    • 2015-01-24
    • 1970-01-01
    • 2011-09-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-08-02
    • 1970-01-01
    相关资源
    最近更新 更多