scala – SBT中任务和命令之间的差异和相似之处

我最近被指示不要混淆 this answer上的任务和命令,这让我首先意识到甚至存在差异.在我的研究过程中,混淆甚至更多,我必须承认,我显然无法将两者分开！我认为主要的问题是术语经常被同义地使用,但概念是不同的,高度相关并且在某种程度上非常相似.
阅读文档并没有让我满意.我不想在sbt文档中明确显示问题,所以不要误解我,但我希望你能看到我目前的进展.我在旅途中将我的问题标记为大胆,并在其前面添加了一个数字.

研究

我咨询的第一个资源是文档中的Tasks and Commands部分,它仅指向入门指南.

入门

入门指南并没有真正解释这方面的差异.
特别是Defining tasks and settings部分似乎引入了更多的混乱,其中的类型之间存在着意义;设置[T],设置[任务[T]],任务[T]和键的术语及其对应的类型.

A TaskKey[T] is said to define a task. Tasks are operations such as compile or package. They may return Unit (Unit is Scala for void),or they may return a value related to the task,for example package is a TaskKey[File] and its value is the jar file it creates.

这有点古怪但现在还可以,因此Tasks是TaskKey实例,其结果类型为T.

Each time you start a task execution,for example by typing compile at the interactive sbt prompt,sbt will re-run any tasks involved exactly once.

因此,任何任务都可以在sbt提示符下找到.那么命令的区别在哪里呢？在进一步的部分,两者似乎都是同义词,如here.第More About Settings节进一步描述：

Remember that some settings describe tasks,so this approach also creates dependencies between tasks.

因此,任务可能相互依赖,由设置引入.

A plugin extends the build definition,most commonly by adding new settings. The new settings could be new tasks. For example,a plugin could add a codeCoverage task which would generate a test coverage report.

插件可能会使用设置引入新任务.

Also remember from .sbt build definition that a setting has a fixed value until project reload,while a task is re-computed for every “task execution” (every time someone types a command at the sbt interactive prompt or in batch mode).

这让我觉得命令只是在sbt提示符下输入的内容,或者是使用批处理模式直接输入到终端的命令.此外,它产生了一个想法,即命令仅作为每个任务的浅前端. #1每个任务都有相应的命令吗？

By defining triggered plugins,auto plugins can be used as a convenient way to inject custom tasks and commands across all subprojects.

在这里,我认为命令可以单独设置 – 类似于任务.但是,第Running Commands节讨论了为命令或任务创建别名,但没有说明任何有关任务的内容.我觉得这些概念可能是相同的,虽然我知道两者都不同.

任务

以下是与Tasks页面相关的任务功能列表：

>通过与设置系统集成,可以像设置一样轻松灵活地添加,删除和修改任务.
>输入任务使用解析器组合器来定义其参数的语法.这允许灵活的语法和制表符完成与命令相同.
>任务产生价值.其他任务可以通过在任务定义中调用其中的值来访问任务的值.
>可以动态地更改任务图的结构.可以根据另一个任务的结果将任务注入执行图.
>有办法处理任务失败,类似于try / catch / finally.
>每个任务都可以访问自己的Logger,默认情况下会以比最初打印到屏幕更详细的级别保留该任务的日志记录.

在功能之上,它进一步说：

Settings are evaluated at project load time. Tasks are executed on demand,often in response to a command from the user.

好的,所以一些任务可以通过其他方式启动.

命令

最后command页面说明：

A “command” looks similar to a task: it’s a named operation that can be executed from the sbt console.

所以现在我认为对来自sbt提示符或批处理的指定任务或命令的任何调用都被称为命令.无论命令是指向任务还是命令实例. #2因此,区分定义和呼叫级别是否有意义,以减少不确定性？例如：在调用级别,一切都是命令,但在定义级别,这是一个Command或TaskKey实例.

这是一段代码,显示了命令定义的一般解剖：

val action: (State,T) => State = ???
val parser: State => Parser[T] = ???
val command: Command = Command("name")(parser)(action)

因此命令的动作是状态转换,使其在函数式编程方面具有高度可组合性.相比之下,作为TaskKey [T]实例的任务更像是返回类型T的结果的简单函数.特征列表中的点3表示任务产生的值使得我认为任务更像纯粹的函数生成除了返回类型为Unit的任务之外,只有一些小的副作用,如第6点所述的记录.

However,a command’s implementation takes as its parameter the entire state of the build (represented by State) and computes a new State. This means that a command can look at or modify other sbt settings,for example. Typically,you would resort to a command when you need to do something that’s impossible in a regular task.

所以我认为命令在某些情况下有点优越.然后我问自己：任务和命令是否共享关于任务功能列表的相同功能子集,如明显的第2点？第1点指出,由于设置系统的集成,可能会对设置进行任意修改,对于命令也不是这样吗？对于第4点,第5点和第6点也是如此.#3有人可以澄清这一点,特别是限制并说明我何时应该客观地使用命令而不是任务或者(计数器)示例何时不这样做？