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

在确保阅读并理解general context之前，请不要关闭或标记为重复。 识别问题点花费了很多精力。

需要的功能

Go需要一个官方的go mod pack命令，该命令处理一组解包的Go模块，并生成相应的打包模块文件以供重用(如goproxy中所述)。这与#27858的问题不同，因为#27858希望将生成的文件放入模块缓存中，将它们与其他来源的模块混合在一起，并禁止除当前用户之外的任何人重用结果。

约束条件

• 该功能还应作为官方Go API中的函数公开
• 输入集可以定义为一个或多个go.mod文件系统路径列表(如issue cmd/go: [modules + integration] go mod discover, discover a set of unpacked modules within a directory #31299中由go mod discover产生的),一个或多个目录路径(类似于issue cmd/go: [modules + integration] go mod discover, discover a set of unpacked modules within a directory #31299中定义的目录路径),或者两者的混合
• destination应该是用户指定的任何二进制目录路径
• 为了与现有工具的兼容性，一个单独的可选prefix标志应该允许在目标前添加路径：
• 即假装在destination上工作，实际上在filepath.Join(prefix, destination)上工作
• 这通常用于准备部署到canonical_path,使用一个/prefix/canonical_path暂存目录
• 为了与CI/CD软件集成，该命令应可选地将创建的文件列表以机器可读格式输出到用户指定的结果文件
• 结果文件路径不受destination的影响
• 结果文件列表不包含prefix,因为命令正在假装直接写入destination
• 这与go mod build(cmd/go: [modules + integration] go mod build, build all the binaries provided by a module #31323)的行为相似，应使用相同的约定
• 该命令应使用发现的与相应mod文件相邻的info文件中的版本信息
• 该命令还应接受用户提供的版本信息作为输入，要么在缺少info文件时填充空白，要么覆盖它们(这两种策略都可以认为是有效的)
• 该命令应默认整理mod文件，删除不需要的需求(但也请参阅cmd/go: [modules + integration] tidy a specific module descriptor #31318)
• 该命令应在安全的无互联网下载模式下工作。在这种模式下，它可能应该将其整理限制为直接依赖项和配置的goproxy源中可用的依赖项(cmd/go: [modules + integration] use several goproxy sources simultaneously #31304)
• 该命令还可以生成/更新相应的list索引文件(但也请参阅更一般的cmd/go: [modules + integration] go mod index, reindex a goproxy directory #31303,无论如何都需要)

动机

在Go模块世界中创建和管理第三方代码的基础要求能够生成作为单独CI/CD运行中的基准块的go模块文件。