本报告是一系列报告的一部分，应@mdempsky的要求编写，重点是为Go模块集成者提供友好的体验。

在确认阅读并理解general context之前，请勿关闭或标记为重复。为了准确地识别问题点，我们投入了大量的工作。

需要的功能

Go需要一个官方的go mod requires命令，该命令可以处理打包的Go模块文件，并返回在其他代码中使用此模块所需的依赖项列表。
go mod requires可以通过特定的选项标志实现为go mod graph模式，或者作为单独的子命令。它是go mod buildrequires(#31300)的补充，用于在go mod buildrequires分析后为CI/CD系统填充作业运行时环境。

约束条件

• 输出应该是机器可读的：
• 模块路径
• 最小版本
• 该功能还应该作为官方Go API中的函数暴露出来，返回一个go对象(Map、列表、结构体等)
• 输出应该预先过滤，或者可以通过以下方式轻松过滤，而无需进一步调用go工具：
• GOOS(仅返回此GOOS的结果)
• GOOS+GOARCH(仅返回此GOOS和GOARCH的结果)
• 完整的构建上下文(GOOS+特定的构建标志集)
• 输出应该预先过滤，或者可以通过直接和间接的需求轻松过滤：
• 代码重用需求(需要在其他项目中使用的模块)
• 编译器测试需求(仅需要编译器的模块来运行测试)
• 集成测试需求(需要运行测试的模块，需要比仅需要编译器运行更多的内容，可能无法通过平均的CI/CD系统满足):
• 互联网访问权限
• root访问权限
• 某些特定软件示例
• 某些凭据等
• 该命令应在安全的无下载、无缓存模式下工作。在这种模式下，它可能会将其输出限制为直接依赖项。

动机

• 这几乎就是go mod graph已经做的事情，只是这个请求要求更细粒度的依赖关系视图。因此，如果希望保持go mod graph输出的整体性和非过滤性，这将是一个自然的go mod graph扩展。唯一需要的是如果有额外的需求的话，可以添加一个单独的子命令。
• 更细粒度的视图是必需的，因为在繁忙的构建农场上，向CI/CD构建环境添加比运行所需的严格最低限度更多的代码会变得非常昂贵。因此，构建需求列表需要尽可能减少，以便删除特定GOOS/GOARCH上不需要的需求。GOOS/GOARCH是最精细的过滤模式，允许模块重用。GOOS/GOARCH是所有希望重用该模块的其他代码共享的约束条件。这是其他特定于项目构建标记的情况所不具备的。
• 在集成模式下，任何已经通过CI/CD集成管道并被项目基线接受的go module都已经通过了所有单元测试。因此，将这些单元测试的依赖项注入到重用此模块的作业中是不必要的且不理想的。
• 缺失的模块通常会从组织基线中填充。因为这个基线可以在组织项目之间共享，所以不会在每个项目的VCS目录中镜像。
• 需要的模块，由go mod requires调用确定，通常会从组织基线中填充。
• 将新模块添加到组织基线是一项艰巨的工作。它需要：
• 分配一个策展团队
• 在分叉之间筛选出实际上游项目
• 在VCS镜像之间筛选出根VCS
• 法律分析
• 测试结果分析
• 为CI/CD系统编写相应的配方等
• 因此，在咨询过集成商之后，他们对强制处理新模块以满足相应导入的存在感到极度怀疑和拒绝：
• 当此GOOS/GOARCH不是组织目标的一部分时，依赖于GOOS/GOARCH特定代码的依赖项
• 当它们在我们CI/CD设置中永远不会运行时上游集成测试的依赖项，因为它们使用了不可用的内容(通常是直接互联网调用或root访问)
• 示例代码永远不会在生产环境中使用，并且通常无法编译，因为它们的上游没有保持更新状态