现有技术

为什么又是一个任务运行/子进程触发的 Python 库？像往常一样，简短的回答是：”现在已经有 80-90% 的优秀解决方案了，但没有一个能 100% 满足我们的需求。” 具体来说：

• 一次完成多个任务 – 几乎没有其他面向 Python 命令行的库允许 invocations 像

  runner --core-opts task1 --task1-opts task2 --task2-opts
  

  而为数不多的是对该功能的半生不熟的实现，或在其他方面有所欠缺。

• 能够同时镜像和捕获子进程的输出 （除了由此产生的一切，如透明的自动响应能力）– 标准库的 subprocess 不能做到这一点，大多数其他工具选择一个或另一个，或有其他权衡，如不支持（或只支持！）伪终端。

• 简单性 – 试图做很多事情的工具往往会因此受到影响，因为缺乏重点。我们想建立一些干净和简单的东西，只做一件事（好吧……两件事）就好。

• 可定制性/控制 – Invoke 被设计为与其他工具（并成为其基础）很好地合作，如 Fabric 的第二个版本，我们认为为实现这一目标而调整现有工具所需的工作将阻碍进展。

在 Python 世界中，这一领域的一些预先存在的解决方案包括：

• Argh： 这是一个比较吸引人的选择，但由于它是建立在 argparse 上的，所以不支持我们需要的多任务调用。它也有自己的 “prior art” 列表，值得你花点时间。

• Baker：不错，很简单，但不幸的是，对我们的需求来说，太简单了。

• Paver：试图做太多的事情，笨重的 API，用户讨厌的错误信息，多任务功能存在但缺乏。

• Argparse：现代 CLI 解析的黄金标准（尽管没有命令执行）。不幸的是，尽管做了很多实验，我们还是无法让多个任务工作。多个任务的参数名称有可能重叠，这与 argparse 对命令行的思考方式不一致。

• Click: 实际上并不存在（Invoke 的第一次公开发布比 Click 早了好几年），但它还是值得一提，因为它在这个特殊的利基市场上已经很受欢迎。