Typer 升级到 0.26.0 后，依赖内部 Click 应用或 Click 专用类型的应用怎么适配？

Typer 升级到 0.26.0 后，依赖内部 Click 应用或 Click 专用类型的应用怎么适配？

【免费下载链接】typerTyper, build great CLIs. Easy to code. Based on Python type hints.项目地址: https://gitcode.com/GitHub_Trending/ty/typer

如果你的项目用了 Typer，并且代码里直接取了 Typer 应用内部的 Click 应用（.click）来挂 Click 专用插件，或者用 Click 专用类型（如click.types中的类型）定制过参数解析，那么升级到 Typer 0.26.0 时这类功能会被移除。Typer 从 0.26.0 起把 Click 的源码直接内置（vendored）到 Typer 内部，不再把 Click 作为第三方依赖安装，Typer 与内置 Click 源码之间的交互也统一重构了。结果是：过去可以"提取内部 Click 应用并用任意 Click 功能修改它"的用法不再受支持。这篇文档对应的仓库页面是 Vendored Click 说明，版本记录在 Release Notes。

哪些代码会受影响

先判断自己的应用是否落在受影响的范围内，有两种典型模式：

1. 提取内部 Click 应用：对typer.Typer()创建的app访问其内部的 Click 应用（.click），用它做 Typer 本身没有暴露的操作，官方文档举的例子是挂载 Click 专用插件（Click-specific plug-ins）。
2. 使用 Click 专用类型：导入 Click 的类型并用它们覆盖 Typer 默认的字段类型（即 release notes 中的 "customizing the field types with Click-specific types"）。

只要你的代码里有上面任意一种，就属于官方文档定义的受影响的边缘用法；只使用标准 Typer 写法（typer.Option/typer.Argument、标准 Python 类型注解）的应用不需要做任何事。

官方给出的两条迁移路径

官方文档对这个场景的结论很明确：这个功能不再支持，如果你的应用确实依赖了它，只有两条路——

要么把应用迁移为纯 Typer 写法，要么改为直接使用 Click 而不是 Typer。

路径一：迁移为纯 Typer（大多数情况的默认选择）

多数"借 Click 做一点额外事"的需求，Typer 已有原生等价物。以文档中实际出现过的两个例子说明替换方式：

替换 Click 专用类型。不再从 Click 导入类型来定制参数，改用标准 Python 类型加 Typer 参数声明。例如文件参数用pathlib.Path加typer.Option即可，Typer 内置了对应的参数类型支持（教程示例见 docs/parameter-types 一节）：

import typer from pathlib import Path app = typer.Typer() @app.command() def main( path: Path = typer.Option(..., exists=True), ) -> None: print(path) if __name__ == "__main__": typer.run(main)

替换对内部 Click 应用的直接操作。Typer 对补全这类能力有原生参数。以补全为例，源码中的兼容层（见 typer/core.py）表明：在 Typer 里只有autocompletion参数受支持，此前对 Click 的shell_complete的支持已发出DeprecationWarning，并说明 "will be removed in upcoming versions"。也就是说，原来通过 Click 参数设置补全的地方，应改为 Typer 的autocompletion参数：

import typer from pathlib import Path def path_completer(incomplete: str): return [p for p in Path().glob("*.py") if p.name.startswith(incomplete)] app = typer.Typer() @app.command() def main( file: Path = typer.Argument(..., autocompletion=path_completer), ) -> None: print(file) if __name__ == "__main__": typer.run(main)

（以上第二段代码是依据源码兼容层行为整理的示例，补全函数按自己应用的取值范围实现。）

路径二：改用 Click 直接写

如果应用的核心逻辑本身就构建在 Click 的插件机制或 Click API 上，用纯 Typer 表达不划算，就按官方建议整体迁移到直接用 Click 实现，不再经过 Typer。

验证迁移是否完成

1. 从依赖声明中移除对click包的直接依赖，重新安装环境后运行应用。
2. 应用正常启动，--help和各命令可用。
3. 逐项跑一遍迁移前依赖 Click 的那些行为（插件加载、参数类型解析、补全），确认行为不变。
4. 确认代码中不再残留对click的导入以及对 Typer 应用内部 Click 实例的访问——0.26.0 后这些访问没有受支持的行为保证。

限制与边界

• 0.26.0 之后，Typer 基于内置的固定版本 Click 源码（仓库中内置自 Click 8.3.1，见 docs/alternatives.md）独立演进，"Click 新版本的功能或变化"不会再传导到 Typer；文档同时明确：随着 Typer 继续改进和扩展，一部分 Click 功能未来将不再可用。
• 仓库中typer/_click/目录是内置（vendored）的 Click 源码，不是公共 API。适配过程不应新增对它的导入或依赖。
• 升级 Typer 本身没有附带需要执行的迁移命令；需要改的是应用代码（以及依赖声明），改完按上一节验证。

【免费下载链接】typerTyper, build great CLIs. Easy to code. Based on Python type hints.项目地址: https://gitcode.com/GitHub_Trending/ty/typer