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

Question

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

研究

我咨询的第一个资源是文档中的" 任务和命令"部分,它仅指向入门指南.

入门

入门指南并没有真正解释这方面的差异.特别是定义任务和设置部分似乎引入了更多的混淆,以及类型之间的目标; Setting[T],Setting[Task[T]],Task[T]和键和与其对应的类型的术语.

TaskKey[T]据说A 定义了一个任务.任务是诸如compile或之类的操作package.它们可能返回Unit(Unit为Scala void),或者它们可能返回与任务相关的值,例如packagea TaskKey[File],它的值是它创建的jar文件.

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

每次启动任务时,例如通过compile在交互式sbt提示符下键入,sbt将重新运行一次涉及的任何任务.

因此,任何任务都可以在sbt提示符下找到.那么命令的区别在哪里呢？在其他部分,两者似乎都是同义词,就像这里一样." 更多关于设置 "部分进一步描述:

请记住,某些设置描述了任务,因此这种方法也会在任务之间创建依赖关系.

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

插件扩展了构建定义,最常见的是添加新设置.新设置可能是新任务.例如,插件可以添加codeCoverage任务,该任务将生成测试覆盖率报告.

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

还要记住.sbt构建定义,设置在项目重新加载之前具有固定值,而每次"任务执行"都会重新计算任务(每次有人在sbt交互式提示符或批处理模式下键入命令时).

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

通过定义触发的插件,可以使用自动插件作为跨所有子项目注入自定义任务和命令的便捷方式.

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

任务

以下是" 任务"页面中与任务相关的功能列表:

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

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

在项目加载时评估设置.任务按需执行,通常是响应用户的命令.

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

命令

最后,命令页面指​​出:

"命令"看起来类似于任务:它是一个可以从sbt控制台执行的命名操作.

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

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

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

所以command的action是一个状态转变,这使得它在函数式编程方面具有高度可组合.与之相比,作为TaskKey[T]实例的任务更像是返回类型结果的简单函数T.功能列表中的第3点表示任务产生的值使得我认为任务更像纯粹的函数,只产生一些小的副作用,如第6点所述的日志记录,除了返回类型为的任务Unit.

但是,命令的实现将构建的整个状态(由State表示)作为其参数,并计算新状态.例如,这意味着命令可以查看或修改其他sbt设置.通常,当您需要执行常规任务中不可能执行的操作时,您将使用命令.

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

Answer 1

尽可能尝试使用任务。它们更容易理解，也更容易编写。

从文档：

通常，当您需要执行常规任务中不可能执行的操作时，您会使用命令。

如果没有指定任务的限制是什么，那当然无济于事。然而，我个人认为它的意思是：如果你想操纵state构建的 ，你可以使用命令。

这方面的一个例子是当您想要使用不同的设置运行任务时。

任务使您可以访问其他设置和任务，命令还可以让您访问状态并允许您对其进行操作。然而，这是以其他开发人员不熟悉和增加复杂性为代价的。

在某些情况下，某些内容既可以表示为任务，也可以表示为命令。在这里，我会采取选择一种感觉更容易的方法。