CLI辅助输入、源和输出的版本控制

Question

我目前在这样一个环境中工作：

1. 多个输入(有多个版本)
2. 生成输出的源代码(多个版本)
3. 由输入和源代码组合而产生的输出

顶层目录如下所示：

inputs/
outputs/
src/

我想稍微概括一下这个概念，并创建一个脚本，帮助我自动跟踪生成给定输出所需的信息。

到目前为止，我已经确定了以下层次结构，以帮助我做到这一点：

输入/

我将在一个文件夹中记录每一组离散的输入。虽然使用Git是可能的，但是在Git中跟踪大型的、可能是二进制的文件仍然是不可行的。因此，例如，我将这样设置这个目录结构：

inputs/inputs-1-v1
inputs/inputs-1-v2
inputs/inputs-1-v3
inputs/inputs-2-v1

src/

源代码，版本由Git控制。它们代表着不同的实验或分析，可以是任意的语言。示例：

script-1
script-2

输出/

假设输入/输入-1-v1作为脚本-2的输入。然后，生成结果输出文件夹：

outputs/script-2/git-hash/inputs-1-v1

这个结构是灵活的，我现在只是在想它，但并不是我为什么要问我的问题。我觉得有必要给出一些背景。

问题(S)

目前，我正计划编写一个“主”脚本，该脚本可以用于这个通用项目体系结构，可以从顶层目录运行：

run -c "script parameter 1 parameter2" -i <inputs folder>

这将导致一个简单的命令扩展到以下内容：

src/script parameter1 parameter2 -i ../inputs/input-folder -o ../outputs/script/git-hash/input-folder > ../outputs/script/git-hash/input-folder/stdout.txt 2> ../outputs/script/git-hash/input-folder/stderr.txt

不过，我觉得这很笨重。它强制我的脚本公开接受-i和-o参数的CLI。这就引出了为什么我会首先编写这样一个主脚本的问题，但是我想抽象出创建这些输出文件夹的想法是一个很好的计划，而不是在多个单独的脚本中重复这个逻辑。

我认为最让我困扰的是缺乏正式接口的声明。我要求实现者将这些-i和-o选项添加到脚本中。例如，如果这是一个Java类，我可能会创建一个实验接口并让script1实现它。

我直觉地认为应该发生的是更统一的事情，在这种情况下，我可以从输入文件夹中管道输入，只需重定向脚本的输出，而不必显式地让脚本写入文件。但是，脚本可能会编写多个文件(图像文件、文本文件等)，这使这一事实更加复杂。以及从多个文件中读取一个给定的输入。

因此，总括而言，我是问：

• 这里还有其他可能的方法吗？
• 脚本上的任意语言约束是否妨碍了更好的设计？
• 从软件工程的角度来看，我可以/需要放松哪些约束来使这个设计更好？

我发现了以下相关的问题，但更多的是关于结构的问题。

https://academia.stackexchange.com/questions/36995/how-to-keep-code-and-output-organized

编辑:也许下面的问题更清楚:对于我来说，什么是传达从属脚本应该将其输出写入某个目录的最佳方式？脚本应该知道它应该在哪里编写它的输出吗?还是应该尝试将它写到类似stdout之类的东西上呢？我上面描述的方法要求用户知道他们的脚本需要上面定义的显式接口，我不知道这是否是一个好的设计。

Answer 1

在我看来，以下是答案：

1. 这里还有其他一些可能的方法吗？
   • 只要输入和输出是文本文件，就不难用代码对它们进行版本控制，因此我会这样做，以便删除诸如"input1-v1“和”input1-v2“这样的文件；
   • 尽管如此，我将在项目的根中提供一个makefile，它将包含所有命令(在这个makefile中，主脚本的运行将是一个目标)；run目标将接收作为您正在处理的输入的参数，然后makefile只将这个参数传递给主源代码(必要时通过makefile编译)；
   • 在对所有输入进行处理之后，您可以对输出进行版本化，并将所有内容提交给服务器，创建一个标记，以便将所有实验报告给特定版本。

2. 脚本上的任意语言约束是否妨碍了更好的设计？
   • 如果您使用makefile或其他类似的方法，语言或SDK不应该是一个问题，甚至操作系统也不应该是问题；

3. 从软件工程的角度来看，我可以/需要放松哪些约束来使这个设计更好？
   • 首先，我们需要理解您的关注点、需求和约束；从我得到的信息来看，我建议了实现版本控制需求的上述步骤；我不会根据您在问题中描述的内容更改任何约束。

Answer 2

编码程序

中的输入/输出文件命名方案

考虑将输入/输出文件命名方案放到程序中即可。如果这样做，那么您的参数将指定输入目录；输出目录的路径将自动从基本输出目录和输入目录名派生出来。基本输出目录可以是硬编码的，或者相对于输入目录，或者相对于可执行文件。您可能允许参数覆盖基本输出目录以进行测试。

为每个输入目录

编写一个小脚本

在这种方法中，为每个输入目录创建一个小脚本。该脚本对输出目录进行编码。这将替换您所设想的逻辑，只需创建一个脚本并在正确的目录中键入。这将输出目录名从“全自动”转到“半自动”：在创建脚本时，只需手动配置输出目录一次。

使用make

在这种方法中，您可以使用make来运行程序(可能还可以构建它)。Make封装规则以从输入目录派生输出目录。如果愿意，可以将make配置为在程序更改或输入数据更改时重新运行程序。如果需要，可以创建针对每个输入目录运行程序的规则。

这是我最喜欢的方法:这就是make设计的目的。虽然它的DSL可能有点神秘，但它对于这样的事情非常有效。