Question

有那么多库可以用来编写命令行实用程序；为什么 Click“存在”？

这个问题很容易回答：因为没有一个针对 python 的命令行实用程序可以勾选以下框：

• 无拘无束
• 支持执行 unix/posix 命令行约定
• 支持将环境变量中的值从框中加载
• 支持提示自定义值
• 完全可嵌套且可组合
• 在 python 2 和 3 中的工作原理相同
• 支持开箱即用的文件处理
• 附带有用的通用帮助程序（获取终端尺寸、ANSI 颜色、获取直接键盘输入、屏幕清除、查找配置路径、启动应用程序和编辑器等）。

Click 有很多选择，如果你更喜欢的话，你可以看看它们。显而易见的是 optparse 和 argparse 来自标准库。

click 实际上实现了它自己的参数解析，并且不使用 optparse 或 argparse 跟随 optparse 分析行为。它不基于的原因 argparse 那是 argparse 不允许通过设计正确嵌套命令，并且在符合 POSIX 的参数处理方面存在一些缺陷。

Click 是为了好玩的工作，同时不妨碍你的方式。它也不太灵活。例如，目前它不允许您自定义过多的帮助页面。这是有意的，因为 click 的设计允许您嵌套命令行实用程序。其思想是，通过将两个 Click 实例连接在一起，您可以拥有一个与另一个系统协同工作的系统，并且它们将继续按其应该的方式工作。

太多的可定制性会破坏这一承诺。

已写入 Click 以支持 Flask 微框架生态系统，因为没有工具能够提供它所需要的功能。

为了了解 Click 的所有功能，我强烈建议您查看 复杂的应用 一章来看看它对什么有用。

为什么不 argparse？

Click 是基于 optparse 而不是 argparse 的内部操作。然而，这是一个用户不必关心的实现细节。但是，click 不使用 argparse 的原因是它有一些问题行为，使得处理任意命令行接口变得困难：

• argparse 有内置的魔术行为来猜测某个东西是参数还是选项。当处理不完整的命令行时，这会成为一个问题，因为如果不完全了解命令行解析器的行为，就不可能知道这一点。这违背了 Click 将其分配到子组的野心。
• argparse 当前不支持禁用分散的参数。如果没有这个特性，就不可能安全地实现 click 的嵌套解析特性。

为什么不 Docopt 等？

Docopt 和许多类似于 it 的工具在工作方式上都很酷，但是很少有工具像 click 那样处理命令嵌套和可组合性。据开发人员所知，click 是第一个旨在创建超出系统本身支持的应用程序可组合性级别的 Python 库。

例如，Docopt 通过解析帮助页面，然后根据这些规则进行解析来执行操作。这一点的副作用是，docopt 在处理命令行接口方面非常严格。docopt 的优点是它能让您对帮助页面有很强的控制力；缺点是，由于这个原因，它不能重新包装当前终端宽度的输出，而且它会使翻译变得困难。除此之外，docopt 仅限于基本解析。它不处理参数调度和回调调用或类型。这意味着除了基本的帮助页面之外，还需要编写许多代码来处理解析结果。

然而，最重要的是，它使可组合性变得困难。虽然 docopt 支持分派到子命令，但它不直接支持基于可用内容的任何类型的自动子命令枚举，也不强制子命令以一致的方式工作。

这很好，但它不同于 Click 的工作方式。Click 目标通过执行以下操作来支持完全可组合的命令行用户界面：

• Click 不只是解析，它还发送到适当的代码。
• click 有一个强大的调用上下文概念，它允许子命令响应来自父命令的数据。
• Click 具有可用于所有参数和命令的强大信息，因此它可以为完整的 CLI 生成统一的帮助页，并在必要时帮助用户转换输入数据。
• Click 对类型有很强的了解，如果出现问题，它可以向用户提供一致的错误消息。由不同的开发人员编写的子命令不会因错误消息而突然死亡，因为它是手动处理的。
• Click 有足够的元信息可供整个程序使用，因此它可以随着时间的推移而发展，从而在不强制开发人员调整程序的情况下改善用户体验。例如，如果 Click 决定更改帮助页的格式，则所有 Click 程序都将自动从中受益。

Click 的目的是制造可组合的系统，而 docopt 的目的是构建最漂亮和手工制作的命令行界面。这两个目标以微妙的方式相互冲突。Click 积极地阻止人们实现某些模式，以实现统一的命令行界面。例如，您对重新格式化帮助页的输入很少。

为什么要硬编码行为？

另一个问题是为什么 Click 远离 optparse 并硬编码某些行为，而不是保持可配置性。这有多种原因。最大的一个问题是，过多的可配置性使得很难获得一致的命令行体验。

最好的例子是 Optparse 的 callback 接受任意数量参数的功能。由于命令行的语法不明确，无法实现完全可变的参数。总是需要权衡，如果 argparse 这些权衡已经足够关键了，像 click 这样的系统甚至不能在上面实现。

在这种特定的情况下，Click 尝试保留一些公认的用于构建命令行接口的范例，这些范例可以很好地记录和测试。

为什么不自动更正？

问题出在 optparse 和 argparse 都支持自动扩展长参数的情况下，为什么 click 不自动更正参数。这样做的原因是它对向后兼容性负有责任。如果人们开始依赖自动修改的参数，并且将来有人添加了一个新参数，脚本可能会停止工作。这类问题很难找到，所以 Click 不会试图对此产生魔力。

但是，这种行为可以在更高的级别上实现，以支持诸如显式别名之类的事情。有关详细信息，请参阅 命令别名 .