mypy daemon 如何配合 --cache-fine-grained 与 --use-fine-grained-cache 使用远程缓存【免费下载链接】mypyOptional static typing for Python项目地址: https://gitcode.com/GitHub_Trending/my/mypy如果你的代码库很大并且日常通过 mypy daemondmypy反复做类型检查你会遇到一个具体问题daemon 每次启动或重启后的第一次dmypy check仍需处理几乎全部代码等待时间长。mypy 的官方文档给出了一条性能优化路径在 CI 中用--cache-fine-grained生成包含细粒度依赖信息的缓存按 commit 上传为远程缓存开发机把对应缓存下载回本地.mypy_cache目录再用--use-fine-grained-cache启动 daemon让第一次dmypy check复用缓存而不是重新处理整个程序。文档称远程缓存在大型代码库中有时能让 mypy 提速 10 倍甚至更多daemon 场景下“第一次dmypy check应该会快得多”。该方案的前提文档明确列出你已经有一套 CI 系统并且使用中心化的 git 仓库。mypy 本身不包含搭建远程缓存所需的全部组件需要你做一些简单的 CI 或构建系统集成。下面按 CI 侧、开发机侧、daemon 启动三段展开。两个标志各自的职责理解这条路径的关键是分清两个标志分别作用在哪一侧--cache-fine-grained在普通mypy命令行构建中生效作用是“在缓存中包含供 mypy daemon 使用的细粒度依赖信息”。mypy daemon 需要这类额外的依赖数据而缓存文件中默认不包含它。文档中 command_line.rst 对它的说明是Include fine-grained dependency information in the cache for the mypy daemon.配置文件中对应cache_fine_grained项布尔值默认False见 config_file.rst。--use-fine-grained-cache只在 daemon 侧使用文档要求把它传给dmypy start或dmypy restartdaemon 才能使用上面写入缓存的额外信息。完整流程见 additional_features.rst 的 “Using a remote cache to speed up mypy runs” 一节daemon 相关细节在 mypy_daemon.rst。在 CI 中生成并上传细粒度缓存远程缓存由三个组件构成存放缓存文件的共享仓库、负责上传缓存的 CI 构建、开发者使用的 wrapper 脚本。CI 构建一侧的流程是以普通方式运行 mypy但加上--cache-fine-grained缓存数据会写入.mypy_cache目录文档中的占位写法如下args...替换为你项目常规的 mypy 参数$ mypy --cache-fine-grained args...将.mypy_cache目录打包成 tarball。获取当前 git master 分支的 commit id文档给出的方式是git rev-parse HEAD。以由该 commit id 派生的名字把 tarball 上传到共享仓库。缓存文件的具体存放位置文档给了三种可选形式作为 CI 构建的可下载build artifact、上传到 web 服务器、或上传到 S3取决于你的 CI 系统能力。文档还建议在 CI 中始终运行一次完整的、非增量的 mypy 构建来生成缓存数据因为长期反复增量更新缓存可能导致漂移drift。在开发机下载缓存并准备启动 daemon开发者本地的 wrapper 脚本负责把远程缓存取回本地逻辑按文档描述为确定本地分支基于中心仓库的哪个 commit按约定取origin/master分支典型 git 环境下的命令是git merge-base HEAD origin/master依据上面得到的 merge base commit id从共享仓库下载对应的缓存数据即.mypy_cache目录内容并解压使 mypy 以一个新鲜的.mypy_cache开始工作。之后按下一节启动 daemon 并运行检查。文档给出的几条可选改进代码库达到几十万行以上时更值得关注如果 wrapper 判断 merge base 与上次运行相比没有变化就没有必要重新下载直接复用现有本地缓存即可。如果使用 daemon建议在每次 merge base 或本地分支变化后重启 daemon避免在增量构建中处理大量变更文档指出这通常比“下载缓存 重启 daemon”慢得多。如果本地分支基于非常新的 master commit对应 commit 的远程缓存可能尚未生成缓存生成必然有延迟。文档建议向前查找最近约 5 个 master commit 的缓存数据取其中最旧但可用的那份。如果远程缓存因网络等原因不可访问脚本可以退回普通的增量构建。可以用--cache-dir为不同本地分支维护多个本地缓存目录切回一个已经下载过缓存的已有分支时可继续使用该缓存而不用重新下载。启动 daemon 时使用 --use-fine-grained-cache缓存就位后用dmypy start或dmypy restart启动或重启daemon并在--之后带上--use-fine-grained-cacheoptions...同样替换为你自己的常规参数$ dmypy start -- --use-fine-grained-cache options...dmypy restart等价于先 stop 再 start适合 merge base 变化、或配置/版本改变后重启的场景。dmypy run在配置或 mypy 版本变化时也会自动重启 daemon因此如果你习惯用dmypy run -- flags files一步到位把--use-fine-grained-cache放在--之后同样能让 daemon 以该配置启动但文档明确给出的用法是配合dmypy start/dmypy restart本路径以这两条命令为准。启动后执行检查$ dmypy check files随后修改代码再验证时可用dmypy recheck它检查的是最近一次check或recheck的同一组文件。验证方式文档给出的成功判据是行为层面的而不是固定数值用dmypy status确认 daemon 在运行它会打印诊断信息有运行中的 daemon 时以退出码0结束。按文档说法配置正确时“第一次dmypy check运行应该快得多因为它可以利用缓存信息来避免处理整个程序”。如果第一次 check 仍然接近全量检查的耗时先核对两件事CI 侧是否真的用了--cache-fine-grained生成缓存没有细粒度依赖数据daemon 无法利用缓存以及启动命令是否带了--use-fine-grained-cache。需要停止 daemon 时用dmypy stop排查 daemon 崩溃类问题时可用dmypy start --log-file FILE -- ...把 daemon 的 stdout/stderr 重定向到文件因为服务端 traceback 不总是被客户端打印出来。限制与适用边界远程缓存方案假设你有 CI 系统和中心 git 仓库mypy 不提供现成的上传/下载组件这部分需要自行集成。每个 mypy daemon 进程只支持一个用户和一组源文件同一时间只能处理一个类型检查请求要检查多个仓库需要运行多个 daemon 进程。daemon 始终运行在当前主机上。mypy daemon 要求--local-partial-types自 mypy 2.0 起默认开启。文档提示 mypy daemon 的命令行接口在未来的 mypy 版本中可能变化。自 mypy 0.780 起dmypy 默认启用 follow-imports该功能仍是实验性的如遇到问题可用--follow-importsskip或--follow-importserror回退到稳定行为。【免费下载链接】mypyOptional static typing for Python项目地址: https://gitcode.com/GitHub_Trending/my/mypy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考