升级到较新版本 — 单击文档
升级到较新版本
Click 尝试最高级别的向后兼容性,但有时这并非完全可能。 如果我们需要打破向后兼容性,本文档为您提供有关如何正确升级或处理向后兼容性的信息。
升级到 3.2
Click 3.2 必须对多命令执行两项更改,这些更改是由 Click 2 和 Click 3 之间的更改触发的,其后果比预期的要大。
上下文调用
当与其他命令一起使用时,Click 3.2 包含对 Context.invoke()
功能的修复。 这个函数的初衷是调用另一个命令,当它传递一个上下文对象而不是一个函数时,就好像它来自命令行一样。 这种用法之前只在文档中的一个地方记录过,API 文档中没有对该方法的正确解释。
核心问题是在 3.2 之前,这个调用违背了意图:
这从来没有打算工作,因为它不允许 Click 对参数进行操作。 鉴于此模式从未被记录在案且不怀好意,因此决定在错误修复版本中更改此行为,以免其意外传播并且开发人员依赖于它。
上述命令的正确调用如下:
这也使我们能够解决此功能未正确处理默认值的问题。
多命令链接 API
单击 3 引入了多命令更改。 这需要改变 Click 内部调度的方式。 不幸的是,此更改未正确实施,并且似乎可以提供一个 API,该 API 可以通知超级命令将调用的所有子命令。
但是,此假设不适用于过去提供的 API 保证之一。 因此,此功能已在 3.2 中删除,因为它已被破坏。 取而代之的是恢复了 Context.invoked_subcommand
属性意外损坏的功能。
如果您确实需要知道将调用哪些确切的命令,则有不同的方法可以解决这个问题。 第一个是让子命令全部返回函数,然后调用Context.resultcallback()
中的函数。
升级到 2.0
Click 2.0 有一个重大变化,即参数回调的签名。 在 2.0 之前,回调是用 (ctx, value)
调用的,而现在是 (ctx, param, value)
。 此更改是必要的,否则会使重用回调变得过于复杂。
为了简化过渡,Click 仍会接受旧的回调。 从 Click 3.0 开始,它将开始向 stderr 发出警告以鼓励您升级。
如果您想同时支持 Click 1.0 和 Click 2.0,您可以制作一个简单的装饰器来调整签名:
使用该助手,您可以编写如下内容:
请注意,因为 Click 1.0 没有传递参数,此处的 param 参数将是 None,因此兼容性回调无法使用该参数。