dvc.yaml 是否应该由 dvc run 命令编写或生成？答案

【问题标题】：Is dvc.yaml supposed to be written or generated by dvc run command?dvc.yaml 是否应该由 dvc run 命令编写或生成？
【发布时间】：2021-06-16 14:19:55
【问题描述】：

试图理解dvc，大多数教程都提到通过运行dvc run 命令生成dvc.yaml。

但同时，定义 DAG 的 dvc.yaml 也是well documented。此外，它是 yaml 格式且人类可读/可写这一事实表明它旨在成为用于指定数据管道的 DSL。

有人可以澄清哪种做法更好吗？编写 dvc.yaml 还是让它由dvc run 命令生成？还是由用户自行选择，没有技术差异？

【问题讨论】：

标签： directed-acyclic-graphs data-pipeline dvc

【解决方案1】：

我建议将手动编辑作为主要途径！（我相信这是自DVC 2.0以来官方推荐的）

dvc stage add 对于流水线文件的程序化生成仍然很有帮助，但它不支持dvc.yaml 的所有功能，例如设置vars 值或定义foreach stages。

【讨论】：

感谢您的回答。你能指点我推荐手动编辑的dvc官方文档吗？这将为我解决问题
我认为文档中没有表达，但我记得在 DVC 团队讨论中提到了这一点。最后当然取决于你。无论适合您、您的团队、您的工作流程等。
我发现了这个“注意，我们使用 dvc stage add 命令而不是 dvc run。从 DVC 2.0 开始，我们开始提取 dvc stage 伞下的所有舞台特定功能。dvc run 仍在工作，但将在以下主要 DVC 版本中已弃用（很可能在 3.0 中）。”所以 dvc run 将在 3.0 中被弃用并替换为 dvc stage add 但是对于使用变量，您仍然需要手动编辑 dvc.yaml
dvc repro 还可以防止错误，因为它会在运行时验证 dvc.yaml。 DVC 希望鼓励用户手动编辑 dvc.yaml，这就是它被如此详尽地记录的原因（甚至还有一个 JSON 模式文件）。 stage add 保留用于简单的用例和我认为的向后兼容性，但它是可选的。我怀疑是否有计划通过 CLI 支持高级 dvc.yaml 功能。见github.com/iterative/dvc/issues/5180#issuecomment-752321591（dvc.yaml 2.0 的开发者）。
在讨论中阅读@JorgeOrpinel cmets，我倾向于改变我的回答，将他的回答标记为正确的。我现在明白dvc stage add 和手动编辑 dvc.yaml 之间只有细微的区别，但鉴于原作者在问题中表达了这一点，我相信这将是未来

【解决方案2】：

两者，真的。

主要是dvc run（或较新的dvc stage add，后跟dvc exp run）用于管理您的dvc.yaml 文件。对于大多数（包括临时）用户来说，这可能是最简单的，因此也是最好的。格式会保证正确（类似于在{git,dvc} config之间选择，直接修改.{git,dvc}/config）

但是，正如您所注意到的，dvc.yaml 是人类可读的。这是有意为之，以便更高级的用户可以手动编辑 YAML（可能会使某些验证检查短路，或解锁高级功能，例如 foreach stages）。

【讨论】：

“我们鼓励用户编写 dvc.yaml（而不是）使用 dvc run”来自github.com/iterative/dvc/issues/5180#issuecomment-762643966（dvc.yaml 2.0 开发者）
@JorgeOrpinel 我认为这是一个非常错误引用的上下文摘录。那里的 dvc.yaml 建议特别说明为 a) 尚未费心实施 ${} 支持的一个理由，以及 b) 优于 dvc run 纯粹是因为它预期的弃用但不优于 dvc stage add。如果我错了，请纠正我。