包括第 3 方 protobuffer 定义文件答案

【问题标题】：Including 3rd party protobuffer definition files包括第 3 方 protobuffer 定义文件
【发布时间】：2022-01-20 21:21:09
【问题描述】：

我有一个项目需要创建/读取其他项目生成的 protobuf 文件。

我希望dlprimitives 能够读取格式为ONNX protobuf 和Caffe protobuf 的文件

将它们包含到项目中的最佳方式是什么：

从原始存储库中复制文件，并参考更新源的自述文件
制作 caffe/onnx 外部子项目
在构建时按需下载它们

我的想法：

纯副本不知道它对更新有什么好处
创建巨大的子项目并增加单个文件的克隆时间，因为不可能有一个单一文件的子项目
假设构建环境可以访问互联网。

什么是更好的政策？一般是怎么解决的？

【问题讨论】：

标签： protocol-buffers subproject code-sharing

【解决方案1】：

ONNX 和 Caffe 是 protos 的真实来源，我不鼓励您制作 protos 的副本（因为副本是不确定的）。

对于@eik 的第二点，我认为 protobuf 维护者将 protos 保存在不同的 repos 中是一个很好的做法，以便这些 repos 更容易集成。我认为这应该被认为是最佳实践，但很少这样做。有时，protobuf 维护人员会在每次 proto 更改时生成多语言源代码，但这只是节省了固定成本，当然，您可以随时自己生成 SDK。

您引用的任何原型都没有与 repo 明显不同的版本。这也应该是一种最佳做法。

您应该为您的构建按需克隆|重新创建第 3 方原始存储库，保留存储库的引用并为您需要的任何语言构建客户端。这会保留原始合同（可能是版本化的）并与您的（！）生成的客户端副本同步。

使用您语言的包导入来导入客户端 (pacakges)。例如，使用 Golang，您可以在 go.mod 中添加 replace 以从例如重定向https://github.com/onnx/onnx 到您生成的客户端的副本。

【讨论】：

我需要的第3方没有单独的proto repo的问题...
你可能会。如果第 3 方没有为他们的 protos 发布生成的源代码，您将希望有一个可以生成这些源代码的地方。最合适的候选人在他们的仓库中（你不能这样做），但你可以创建他们的仓库的副本并在那里生成它们。这为您提供了正确命名空间的包（来自原型）。
“按需”克隆可能是一种不好的做法，因为 a) 它使可重现的构建变得不可能（或对旧版本的任何重新构建）并且 b) 您的构建可能随时失败，因为引用存储库中的更改。最好添加一个参考（即 gitmodule），您可以在其中控制更新节奏，并在出现问题时（自动）回滚。这意味着您只需及时引用快照，这相当于仅拥有一份副本，前提是您提供了良好的原始文档。

【解决方案2】：

你所有的方法都是有效的。

协议缓冲区在设计上是向前或向后兼容的，因此手动更新是可以的。您可以通过记录任务或提供脚本/任务来缓解问题。
外部子项目也可以，但您仍然必须手动更新它们（在 git 子模块的情况下）并处理原始项目中更改的路径。您可能需要考虑联系项目并建议将格式描述与主项目分开。
在这种情况下，通常代理或缓存会有所帮助。现在很少有项目在没有外部依赖的情况下构建。

最后，您应该考虑您的目标受众是什么。也许您可以从他们那里获得一些反馈，他们将如何使用您的项目？

【讨论】：