嵌套级别中多个 go.work 的行为?

问题描述 投票:0回答:1

(与

go1.23.3
,如果重要的话)

嵌套目录

./
├── a/
│   ├── a1/
│   │   ├── a1.go
│   │   ├── a2/
│   │   │   ├── a2.go
│   │   │   ├── a2_test.go
│   │   │   └── go.mod
│   │   ├── go.mod
│   │   └── go.work
│   ├── a.go
│   ├── go.mod
│   └── go.work
├── b/
│   ├── b.go
│   └── go.mod
├── c/
│   ├── c.go
│   └── go.mod
└── go.mod

go.mod

  • a
    a1
    a2
    是嵌套的 go 模块。
  • a
    b
    c
    是同一级别的 go 模块。

去工作

  • a/go.work
    :使用
    b
    a2
  • a/a1/go.work
    :使用
    c
    a2

我的测试中,它显示:

  • a2
    可以使用
    b
    ,但不能使用
    c
    ,也就是说
    a/go.work
    生效,是外层
    go.work
  • 如果我删除了
    a/go.work
    ,那么
    a2
    现在可以使用
    c
    ,这意味着
    a/a1/go.work
    生效了。

问题

  1. 这是否意味着在像上面这样的嵌套
    go.work
    中,go 模块将搜索最外层的
    go.work
    并使用它?
  2. 有什么方法可以让
    a/go.work
    a/a1/go.work
    同时生效吗?
    • 2-1.例如:首先搜索最外层
      go.work
      ,如果没有找到,则搜索内部级别,甚至以相反的顺序。
    • 2-2.如果现在不能,你认为这个功能有意义/有用,并且可以在未来的 go 版本中实现吗?
    • 2-3。如果这是一个很好的功能,也许它可以在任何级别 (例如 3) 委托 模式工作(就像
      Java
      classloader 的工作方式一样。)。
    • 2-4。如果这不是一个好功能,或者不是很有用,您能否提供一些推理,谢谢。

@更新

背景(如评论中所述)

  • 通常我不会在实际项目中这样创建多个go.work。
  • 但是,我有一个 git repo 来学习 go 相关技术,每种技术通常有 1 个模块。
    • (我将它们保存在一个 git 存储库中,以便更轻松地提交和检索。)
    • 并且有很多子区域,从而嵌套。
    • 我在最外层有 1 个
      go.work
    • 但是在一个子区域中,该子区域可能有多个相关的 go 模块,这些模块只在子区域内互相使用,所以我在那里创建了一个子 go.work。
      • (我觉得这样更容易管理,2个子区域不会互相干扰。)
    • 有时,出于某种原因,1 个子区域可能需要重用另一个子区域的代码,然后可能需要以某种方式使它们相关。
    • 然后我尝试弄清楚嵌套
      go.work
      的行为,以便我可以更好地决定如何使用
      go.work
      ,因此出现了问题。
go nested go-modules go-work
1个回答
0
投票

(我发现了更多与问题中提到的规则不同的规则。)

规则(我现在找到了)

  • go 模块将选择
    go.work
    那个
    use
    模块。
  • 并且,使用该模块的最外层生效,其他的被忽略。

示例

在问题的目录树中:

  • a/go.work
    生效时间为
    a/a1/a2/go.mod

    因为它是最外面的
    go.work
    使用了
    a2
  • 但是,如果从
    a2
    a/go.work
    语句中删除
    use
    ,则
    a/a1/go.work
    a/a1/a2/go.mod
    生效。
    因为现在
    a/a1/go.work
    成为使用
    go.work
    的最外层
    a2

规则清晰了,现在我可以更好地整理

go.work
文件了。

© www.soinside.com 2019 - 2024. All rights reserved.