在 Go 编程中使用 golang-Debian 包

Question

要理解这个 Go 问题，需要先了解一下 Go modules Debian Packaging 的要点。基本上，Debian 软件包的 Go 模块是这样设计的，它们只能被 Debian 软件包本身使用，而不能用于我们日常的 Go import。

但是，因为它们只是我的操作系统文件系统中的文件，所以我们肯定有办法在我们的日常 Go 中使用 Debian 包import。以前有没有人成功地做到过？

我问的原因是，有很多 github 存储库包含巨大的模块，但我想要的只是其中的一小部分，而那部分恰好已经打包为 Debian 包。即，如果我可以利用它，使用go get会给我带来我大部分不需要的巨大代码库，同时可以让我得到我需要的东西。apt get

Answer 1

AFAIK，您需要附加 /usr/share/gocode到您的GOPATH环境变量（在您自己的私有 Go 工作区之后，以 分隔:）以使这些包可用于go工具链。请参阅本指南（并查看dpkg -L任何感兴趣的已安装 Go 库包的输出——您会看到包的导入路径实际上位于 下/usr/share/gocode/src）。（扩展@Flimzy 在他们对原始帖子的评论中提出的建议，@JimB 在他们的评论中进行了扩展……）您可能需要清楚地说明自己在开发时的意图是什么。“问题”是 Debian 和 Go 管理依赖项的方法存在一定的不确定性：Go 社区建议的常见做法是修复特定版本的依赖项（这些天 - 通过go modules）并让工具链为您获取并安装它们，或者提供您的依赖项 - 这在逻辑上是相同的，但在此如果您实际上将这些依赖项作为代码库的一部分携带（它们只是位于特定目录中）。前者建议用于库代码和一般可供第三方重用的代码，而后者通常用于“最终”产品（通常是内部开发）。Debian 采用的方法是集成：可以理解的是，他们拒绝不受控制地嵌入依赖项的想法，并尝试确保所有与其他任何东西“反向依赖”的东西都被正确打包，理想情况下只有给定的单个版本库存在于任何特定的操作系统版本中（但这在现实生活中并不总是可能的）。这两种方法最终都不是“正确的”，因为它们适用于不同的用例。需要考虑的重要一点是，大多数（如果不是全部）用 Go 编写行业代码的团队将底层操作系统视为一个无聊的实现细节——比如，一个不太有趣的“东西”块，只是需要运行目标产品（如今，通过使用容器将这种方法发挥到了极致）并自行管理它们的依赖关系。这是为什么？这是一个哲学问题。我认为这主要归结为企业中普遍缺乏适当技能的人员来与目标平台进行适当的集成，同时 - 易于维护您自己的经过尝试和测试的依赖项版本，而不是提供的那些由发行版。现在让我们从另一个角度看一下 Debian 打包的 Go 库。Debian 打包程序通过打包 Go 库包来解决他们以集成为中心的任务，这种方式使它们可供 Debian 的构建助手使用（请参阅参考资料dh-golang）。也就是说，在 Debian 中，当您准备一些用 Go 编写的程序的包时，您将不可避免地使用dh-golang确保 Go 工具链以可以利用已安装包的方式调用的东西。现在考虑相当大比例的 Go 库代码，并且许多可运行程序与平台无关，如果您编写的 Go 代码旨在通用，因此将发布在某个地方（例如在一些流行的 Git托管解决方案），最好以任何开发人员都可以抓住它并能够在没有任何特殊准备的情况下对其进行工作的方式来组织代码。所以，我要引导你的是，除非你编写的代码肯定只会在Debian 中使用，否则你的方法可能是正确的，但如果你正在编写“常规”Go 代码，我建议将“编写+维护代码”和“Debian 集成”任务分开——也就是说，按照 Go 社区推荐的方式编写代码，然后编写使用已安装依赖项的 Debian 包。请注意，对于后者，您可能首先需要实际打包所有缺少的依赖项。