Kedro 项目启动全链路解析从python -m与项目入口到KedroSession.run的执行路径【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro导读Kedro 作为一个面向生产级数据科学的工具箱其项目有两种典型的启动方式直接执行$ project命令或通过python -m project以模块方式运行。无论是哪种方式最终都会收敛到同一条核心执行链路Python 入口点 → 查找 run 命令 → 创建KedroSession→ 会话执行run。本文以仓库中 python-m-project.md 的时序图为主线结合源码逐步还原这条链路上每个环节的实现细节帮助你理解 Kedro 项目到底是怎么跑起来的以及插件、cli.py、pyproject.toml在其中各自扮演的角色。一、两条入口一条链路1.1 时序图概述仓库文档 docs/diagrams/python-m-project.md 用一张 Mermaid 时序图直观刻画了python -m {project}的调用过程整条链路共四个参与者cli用户侧的两种启动方式——$ project命令或$ python -m projectentrypointpyproject.toml中声明的入口点project project.__main__:mainfind_runfind_run_command()函数负责定位run 命令sessionKedroSession负责创建会话并执行run。1.2 两种启动方式的等价性$ project与python -m project在 Kedro 项目中最终到达的是同一个__main__.py:main函数$ project是pyproject.toml中[project.scripts]生成的 console script指向{{ python_package }}.__main__:mainpython -m project则直接执行该包的__main__.py。因此两条路径共用同一套入口逻辑时序图中的 Python calls the entrypoint 对两者都成立。项目模板中的入口文件main.py 完整还原了这一逻辑{{ cookiecutter.project_name }} file for ensuring the package is executable as {{ cookiecutter.repo_name }} and python -m {{ cookiecutter.python_package }} import sys from pathlib import Path from typing import Any from kedro.framework.cli.utils import find_run_command from kedro.framework.project import configure_project def main(*args, **kwargs) - Any: package_name Path(__file__).parent.name configure_project(package_name) interactive hasattr(sys, ps1) kwargs[standalone_mode] not interactive run find_run_command(package_name) return run(*args, **kwargs) if __name__ __main__: main()可以看到main()做了三件关键的事从文件路径推导包名Path(__file__).parent.name、调用configure_project()完成项目配置、再委托给find_run_command()取得真正的 run 命令并执行。standalone_mode的取值还保证了该入口在交互式 Python 环境存在sys.ps1下不会抛出 Click 的系统退出异常。二、入口点声明pyproject.toml 的接线作用时序图中的 entrypoint 参与者对应项目模板生成的 pyproject.toml 中的两处关键配置[project.scripts] {{ cookiecutter.repo_name }} {{ cookiecutter.python_package }}.__main__:main [tool.kedro] package_name {{ cookiecutter.python_package }} project_name {{ cookiecutter.project_name }} source_dir src[project.scripts]把命令名默认等于仓库名repo_name绑定到python_package.__main__:main。安装项目后$ repo_name即等价于运行python -m python_package[tool.kedro]段则记录了package_name、project_name、source_dir等 Kedro 项目元信息供kedro工具链识别与引导项目。顺带一提Kedro 框架自身的python -m kedro入口在 kedro/main.py 中也有类似的技巧当sys.argv[0]以__main__.py结尾时会把参数改写为python -m kedro保证kedro --help等输出的一致性与可读性。三、find_run_command()run 命令的分发中心时序图中 Find run command 一步对应的正是 find_run_command()。其核心职责是在项目自定义 CLI、插件、框架默认实现三者之间决定到底该执行哪一个 run 命令。源码逻辑如下def find_run_command(package_name: str) - Callable: try: project_cli importlib.import_module(f{package_name}.cli) # fail gracefully if cli.py does not exist except ModuleNotFoundError as exc: if f{package_name}.cli not in str(exc): raise plugins load_entry_points(project) run _find_run_command_in_plugins(plugins) if plugins else None if run: # use run command from installed plugin if it exists return run # type: ignore[no-any-return] # use run command from kedro.framework.cli.project from kedro.framework.cli.project import run return run # type: ignore[return-value] # fail badly if cli.py exists, but has no cli in it if not hasattr(project_cli, cli): raise KedroCliError(fCannot load commands from {package_name}.cli) return project_cli.run # type: ignore[no-any-return]3.1 三种分发分支场景触发条件返回的 run 命令项目自带cli.pyimport package.cli成功且模块含cli属性project_cli.run安装了带 run 命令的插件cli.py不存在ModuleNotFoundError但插件提供 run插件group.commands[run]均无走框架默认cli.py不存在且无插件kedro.framework.cli.project 中的 run3.2 值得注意的容错细节ModuleNotFoundError会被二次检查只有错误信息确实包含f{package_name}.cli时才优雅降级否则原样抛出——避免吞掉cli.py内部依赖缺失等真正的错误若cli.py存在但没有cli属性则抛出KedroCliErrorCannot load commands from ...即文档注释中所说的fail badly插件分发通过load_entry_points(project)加载kedro.project插件组的命令再由_find_run_command_in_plugins()在插件的commands中寻找名为run的命令见 utils.py。3.3 测试佐证tests/framework/cli/test_cli.py 中 TestFindRunCommand 系列用例对上述三种分支分别做了验证test_find_run_command_non_existing_project包不存在时抛ModuleNotFoundErrortest_find_run_command_with_clipy存在cli.py时返回project_cli.runtest_find_run_command_no_clipy与test_find_run_command_use_plugin_run/test_find_run_command_use_default_run分别验证插件 run 与框架默认 run 的选取路径。四、默认 run 命令从 CLI 参数到 KedroSession当没有任何插件与自定义 CLI 时find_run_command()返回框架默认的 run()。该函数是时序图第三步 create session (for default run) 与第四步 run 的衔接点主要做了以下工作参数互斥校验--pipeline与--pipelines不能同时使用否则抛出KedroCliError--pipeline同时被标记为废弃deprecated推荐改用--pipelines解析运行配置加载SequentialRunner可通过--runner覆盖见load_obj(runner or SequentialRunner, kedro.runner)并通过_resolve_runner_kwargs()处理异步与 runner 参数组装 create/run 参数create_kwargs携带env、conf_source等会话创建参数run_kwargs携带tags、runner、node_names、from_nodes/to_nodes、from_inputs/to_outputs、pipeline_names、namespaces、only_missing_outputs等执行参数创建会话并运行根据settings.SESSION_CLASS是否为KedroSession决定runtime_params传入create()还是run()源码注释明确指出KedroSession在create()接收 runtime_params而KedroServiceSession在run()接收这是 KedroSession 尚未被 KedroServiceSession 完全取代前的过渡方案最终session.run(...)触发整条流水线的执行对应时序图最后的session-session: run。正是find_run_command()的这层分发让 Kedro 的默认 CLI、项目自定义cli.py与第三方插件如 kedro-docker、kedro-airflow 等提供 run 覆盖的插件能够共存并有序竞争。五、configure_project()入口被调用前的隐性一步虽然时序图未显式画出但main()中find_run_command()之前的configure_project()是整条链路能够跑通的前提。该函数定义在 kedro/framework/project/init.py其作用包括加载{package_name}.settings配置模块加载{package_name}.pipeline_registry流水线注册模块将PACKAGE_NAME记录为全局变量源码注释说明ParallelRunner在 Windows 上生成子进程时需要该包名应用项目日志配置LOGGING.set_project_logging(...)可通过preserve_loggingTrue跳过适用于 FastAPI 等长驻进程中自定义 handler 不被覆盖的场景。可以推断一旦configure_project()失败项目设置、流水线注册与日志均不会生效后续find_run_command()与KedroSession的执行也就无从谈起——它是时序图中各参与者之间的地基。六、实战验证路径在仓库内复现这条链路最直接的方式是运行框架自身的模块入口python -m kedro --help以及查看模板项目生成的入口文件、配置文件与测试形成文档 → 模板 → 框架实现 → 测试的闭环时序图原文档docs/diagrams/python-m-project.md项目入口模板main.py入口点与项目元信息声明pyproject.toml框架默认 run 命令实现kedro/framework/cli/project.pyrun 命令分发逻辑与测试utils.py、test_cli.py项目配置与日志初始化kedro/framework/project/init.py七、总结Kedro 项目从$ project或python -m project启动到流水线真正执行本质上是一条职责清晰的分发链入口点entrypoint统一两种调用方式 →find_run_command()在自定义 CLI、插件、框架默认实现之间做出裁决 → 框架默认run()解析参数并创建KedroSession→ 会话执行run。理解这条链路不仅能帮助你排查为什么我的 run 命令没有生效插件 run 与默认 run 谁优先之类的实际问题也为后续深入 KedroSession 生命周期、插件机制与 Runner 体系打下基础。【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kedro 项目启动全链路解析从python -m与项目入口到KedroSession.run的执行路径【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro导读Kedro 作为一个面向生产级数据科学的工具箱其项目有两种典型的启动方式直接执行$ project命令或通过python -m project以模块方式运行。无论是哪种方式最终都会收敛到同一条核心执行链路Python 入口点 → 查找 run 命令 → 创建KedroSession→ 会话执行run。本文以仓库中 python-m-project.md 的时序图为主线结合源码逐步还原这条链路上每个环节的实现细节帮助你理解 Kedro 项目到底是怎么跑起来的以及插件、cli.py、pyproject.toml在其中各自扮演的角色。一、两条入口一条链路1.1 时序图概述仓库文档 docs/diagrams/python-m-project.md 用一张 Mermaid 时序图直观刻画了python -m {project}的调用过程整条链路共四个参与者cli用户侧的两种启动方式——$ project命令或$ python -m projectentrypointpyproject.toml中声明的入口点project project.__main__:mainfind_runfind_run_command()函数负责定位run 命令sessionKedroSession负责创建会话并执行run。1.2 两种启动方式的等价性$ project与python -m project在 Kedro 项目中最终到达的是同一个__main__.py:main函数$ project是pyproject.toml中[project.scripts]生成的 console script指向{{ python_package }}.__main__:mainpython -m project则直接执行该包的__main__.py。因此两条路径共用同一套入口逻辑时序图中的 Python calls the entrypoint 对两者都成立。项目模板中的入口文件main.py 完整还原了这一逻辑{{ cookiecutter.project_name }} file for ensuring the package is executable as {{ cookiecutter.repo_name }} and python -m {{ cookiecutter.python_package }} import sys from pathlib import Path from typing import Any from kedro.framework.cli.utils import find_run_command from kedro.framework.project import configure_project def main(*args, **kwargs) - Any: package_name Path(__file__).parent.name configure_project(package_name) interactive hasattr(sys, ps1) kwargs[standalone_mode] not interactive run find_run_command(package_name) return run(*args, **kwargs) if __name__ __main__: main()可以看到main()做了三件关键的事从文件路径推导包名Path(__file__).parent.name、调用configure_project()完成项目配置、再委托给find_run_command()取得真正的 run 命令并执行。standalone_mode的取值还保证了该入口在交互式 Python 环境存在sys.ps1下不会抛出 Click 的系统退出异常。二、入口点声明pyproject.toml 的接线作用时序图中的 entrypoint 参与者对应项目模板生成的 pyproject.toml 中的两处关键配置[project.scripts] {{ cookiecutter.repo_name }} {{ cookiecutter.python_package }}.__main__:main [tool.kedro] package_name {{ cookiecutter.python_package }} project_name {{ cookiecutter.project_name }} source_dir src[project.scripts]把命令名默认等于仓库名repo_name绑定到python_package.__main__:main。安装项目后$ repo_name即等价于运行python -m python_package[tool.kedro]段则记录了package_name、project_name、source_dir等 Kedro 项目元信息供kedro工具链识别与引导项目。顺带一提Kedro 框架自身的python -m kedro入口在 kedro/main.py 中也有类似的技巧当sys.argv[0]以__main__.py结尾时会把参数改写为python -m kedro保证kedro --help等输出的一致性与可读性。三、find_run_command()run 命令的分发中心时序图中 Find run command 一步对应的正是 find_run_command()。其核心职责是在项目自定义 CLI、插件、框架默认实现三者之间决定到底该执行哪一个 run 命令。源码逻辑如下def find_run_command(package_name: str) - Callable: try: project_cli importlib.import_module(f{package_name}.cli) # fail gracefully if cli.py does not exist except ModuleNotFoundError as exc: if f{package_name}.cli not in str(exc): raise plugins load_entry_points(project) run _find_run_command_in_plugins(plugins) if plugins else None if run: # use run command from installed plugin if it exists return run # type: ignore[no-any-return] # use run command from kedro.framework.cli.project from kedro.framework.cli.project import run return run # type: ignore[return-value] # fail badly if cli.py exists, but has no cli in it if not hasattr(project_cli, cli): raise KedroCliError(fCannot load commands from {package_name}.cli) return project_cli.run # type: ignore[no-any-return]3.1 三种分发分支场景触发条件返回的 run 命令项目自带cli.pyimport package.cli成功且模块含cli属性project_cli.run安装了带 run 命令的插件cli.py不存在ModuleNotFoundError但插件提供 run插件group.commands[run]均无走框架默认cli.py不存在且无插件kedro.framework.cli.project 中的 run3.2 值得注意的容错细节ModuleNotFoundError会被二次检查只有错误信息确实包含f{package_name}.cli时才优雅降级否则原样抛出——避免吞掉cli.py内部依赖缺失等真正的错误若cli.py存在但没有cli属性则抛出KedroCliErrorCannot load commands from ...即文档注释中所说的fail badly插件分发通过load_entry_points(project)加载kedro.project插件组的命令再由_find_run_command_in_plugins()在插件的commands中寻找名为run的命令见 utils.py。3.3 测试佐证tests/framework/cli/test_cli.py 中 TestFindRunCommand 系列用例对上述三种分支分别做了验证test_find_run_command_non_existing_project包不存在时抛ModuleNotFoundErrortest_find_run_command_with_clipy存在cli.py时返回project_cli.runtest_find_run_command_no_clipy与test_find_run_command_use_plugin_run/test_find_run_command_use_default_run分别验证插件 run 与框架默认 run 的选取路径。四、默认 run 命令从 CLI 参数到 KedroSession当没有任何插件与自定义 CLI 时find_run_command()返回框架默认的 run()。该函数是时序图第三步 create session (for default run) 与第四步 run 的衔接点主要做了以下工作参数互斥校验--pipeline与--pipelines不能同时使用否则抛出KedroCliError--pipeline同时被标记为废弃deprecated推荐改用--pipelines解析运行配置加载SequentialRunner可通过--runner覆盖见load_obj(runner or SequentialRunner, kedro.runner)并通过_resolve_runner_kwargs()处理异步与 runner 参数组装 create/run 参数create_kwargs携带env、conf_source等会话创建参数run_kwargs携带tags、runner、node_names、from_nodes/to_nodes、from_inputs/to_outputs、pipeline_names、namespaces、only_missing_outputs等执行参数创建会话并运行根据settings.SESSION_CLASS是否为KedroSession决定runtime_params传入create()还是run()源码注释明确指出KedroSession在create()接收 runtime_params而KedroServiceSession在run()接收这是 KedroSession 尚未被 KedroServiceSession 完全取代前的过渡方案最终session.run(...)触发整条流水线的执行对应时序图最后的session-session: run。正是find_run_command()的这层分发让 Kedro 的默认 CLI、项目自定义cli.py与第三方插件如 kedro-docker、kedro-airflow 等提供 run 覆盖的插件能够共存并有序竞争。五、configure_project()入口被调用前的隐性一步虽然时序图未显式画出但main()中find_run_command()之前的configure_project()是整条链路能够跑通的前提。该函数定义在 kedro/framework/project/init.py其作用包括加载{package_name}.settings配置模块加载{package_name}.pipeline_registry流水线注册模块将PACKAGE_NAME记录为全局变量源码注释说明ParallelRunner在 Windows 上生成子进程时需要该包名应用项目日志配置LOGGING.set_project_logging(...)可通过preserve_loggingTrue跳过适用于 FastAPI 等长驻进程中自定义 handler 不被覆盖的场景。可以推断一旦configure_project()失败项目设置、流水线注册与日志均不会生效后续find_run_command()与KedroSession的执行也就无从谈起——它是时序图中各参与者之间的地基。六、实战验证路径在仓库内复现这条链路最直接的方式是运行框架自身的模块入口python -m kedro --help以及查看模板项目生成的入口文件、配置文件与测试形成文档 → 模板 → 框架实现 → 测试的闭环时序图原文档docs/diagrams/python-m-project.md项目入口模板main.py入口点与项目元信息声明pyproject.toml框架默认 run 命令实现kedro/framework/cli/project.pyrun 命令分发逻辑与测试utils.py、test_cli.py项目配置与日志初始化kedro/framework/project/init.py七、总结Kedro 项目从$ project或python -m project启动到流水线真正执行本质上是一条职责清晰的分发链入口点entrypoint统一两种调用方式 →find_run_command()在自定义 CLI、插件、框架默认实现之间做出裁决 → 框架默认run()解析参数并创建KedroSession→ 会话执行run。理解这条链路不仅能帮助你排查为什么我的 run 命令没有生效插件 run 与默认 run 谁优先之类的实际问题也为后续深入 KedroSession 生命周期、插件机制与 Runner 体系打下基础。【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
