Kedro Starters 使用与自定义指南用 Cookiecutter 模板快速搭建生产级 Kedro 项目【免费下载链接】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 的 Starter 机制展开讲解如何通过kedro new --starter使用官方或自定义模板创建项目、如何利用别名与--checkout进行版本管理以及如何基于prompts.yml、cookiecutter.json和插件入口点构建团队内部可复用的 Starter。读完本文你将掌握从「选模板建项目」到「写模板并发布为别名」的完整链路并能结合仓库源码理解 Kedro 与 Cookiecutter 的协作方式。什么是 Kedro StarterKedro Starter 是一段以 Cookiecutter 模板形式存在的代码用于生成一个完整的 Kedro 项目骨架。使用 Starter 创建项目就像在使用幻灯片或文档软件时套用一个预设布局Starter 决定新项目包含哪些文件、目录、示例代码和工程化配置而 Cookiecutter 负责把这些占位符替换成你输入的实际值。从源码结构看Kedro 将「模板」与「别名」统一定义为KedroStarterSpec对象kedro/framework/cli/starters.py包含四个字段aliasStarter 的别名出现在kedro starter list中也是kedro new --starter的可选入参template_path模板路径可以是本地目录也可以是 Cookiecutter 支持的远程 VCS 仓库地址directory可选字段当同一仓库内含多个模板时用它指定模板所在子目录origin保留字段由 Kedro 内部用来标记 Starter 的来源官方为kedro插件来源则取插件模块名用户无需提供。Kedro 自身的默认项目模板位于 kedro/templates/project当不指定任何 Starter 时kedro new会使用该内置模板源码中通过TEMPLATE_PATH KEDRO_PATH / templates / project定位。如何使用 Starter 创建项目使用 Starter 创建项目只需给kedro new加上--starter参数uvx kedro new --starterpath-to-starter其中path-to-starter可以是以下三种形式之一本地目录路径由 Cookiecutter 支持的远程 VCS 仓库 URLkedro starter list中列出的别名之一。说明使用uvx可以在不把 Kedro 安装进系统或虚拟环境的情况下运行它——每次调用它都会在一个干净的临时环境中下载并执行 Kedro。如果你更习惯标准安装方式例如 pip 虚拟环境请参考 安装指南。当 Starter 存放在远程 VCS 仓库中且该仓库同时包含多个模板时需要通过--directory指定模板所在子目录uvx kedro new --starter githttps://github.com/kedro-org/kedro-starters.git --directory spaceflights-pandas与 Starter 相关的kedro new参数围绕 Starter 的使用kedro new提供了以下几个核心参数均定义在 kedro/framework/cli/starters.py 的new命令上参数简写作用--starter-s指定要使用的 Starter可以是本地路径、远程 VCS URL 或别名--directory-指定仓库内 Starter 所在子目录仅与--starter搭配使用--checkout-检出 Starter 仓库中的某个 tag、分支或 commit--config-c以 YAML 配置文件方式非交互式提供prompts.yml所需的全部键--name-n直接指定项目名跳过交互式输入--tools-t直接指定项目工具如lint,test、all、none不可与--starter混用--example-e是否包含示例 pipeliney/n不可与--starter混用--telemetry-tc项目创建时登记是否允许收集使用分析yes/no从源码的_validate_flag_inputs可以看到两条关键约束--directory不能脱离--starter单独使用Cannot use the --directory flag without a --starter value--starter不能与--example、--tools混用Cannot use the --starter flag with the --example and/or --tools flag。另外--directory只能用于本地路径或远程仓库形式的 Starter不能与别名搭配——源码中如果检测到starter_alias命中别名表且同时传入了directory会直接抛出Cannot use the --directory flag with a --starter alias错误。因为别名本身已经通过KedroStarterSpec.directory携带了目录信息无需再指定。Starter 别名与kedro starter listKedro 团队为常用官方 Starter 提供了别名使用别名时不必写出完整仓库路径。例如使用spaceflights-pandasStarter 创建项目uvx kedro new --starterspaceflights-pandas查看当前支持的全部别名kedro starter list该命令的实现位于 starter.py 的starter list子命令它聚合所有来源的 Starter 规格按origin分组并以 YAML 形式输出每个别名的template_path与directory。官方 Starter 总是排在输出最前面。别名解析的底层逻辑在_get_starters_dict()中它先从核心仓库内置的_OFFICIAL_STARTER_SPECS_DICT收集官方别名再遍历kedro.starters入口点加载插件声明的 Starter如果插件声明的别名与官方别名冲突插件别名会被忽略并打印警告。也就是说插件完全可以扩展这个别名表。官方 Kedro StartersKedro 团队目前维护以下官方 Starter对应 kedro/framework/cli/starters.py 中的_OFFICIAL_STARTER_SPECS全部存放在官方 kedro-starters 仓库的对应目录下template_path统一指向该仓库directory指向各自的子目录别名说明astro-airflow-iris基于 Iris 数据集的示例项目包含在 Airflow Astronomer 平台上部署 pipeline 的最小配置databricks-iris基于 Iris 数据集的示例项目包含针对 Databricks 部署的配置spaceflights-pandasspaceflights 教程的示例代码数据集基于pandasspaceflights-pysparkspaceflights 教程的示例代码数据集基于pysparksupport-agent-langgraph演示使用 LangGraph 构建 agentic 工作流、并借助 Langfuse 或 Opik 进行提示词管理与追踪的示例项目已归档的 Starters以下 Starter 已归档在 Kedro 0.19.0 及之后版本中不可用standalone-datacatalogpandas-irispyspark-irispyspark最后一个支持这些 Starter 的 Kedro 版本是0.18.14。如果你确实需要它们检查当前安装的 Kedro 版本在终端输入kedro -V安装指定版本例如 0.18.14pip install kedro0.18.14在 0.18.14 下创建项目时同时用--checkout锁定 Starter 版本例如使用pandas-iriskedro new --starterpandas-iris --checkout0.18.14。Starter 版本管理--checkout默认情况下Kedro 使用 Starter 仓库中当前可用的最新版本。若想固定使用某个版本可通过--checkout参数指定uvx kedro new --starterspaceflights-pandas --checkout0.1.0--checkout的值可以是 Starter 仓库中的任意分支branch、标签tag或提交commit。底层实现中该值会被原样传递给 Cookiecutter 的--checkout参数。值得注意的默认行为在 starters.py 的_select_checkout_branch_for_cookiecutter中当使用官方别名且未显式传入--checkout时Kedro 会把当前安装的 Kedro 版本号作为默认 checkout 值。这意味着官方 kedro-starters 仓库按 Kedro 版本打 tag 时会自动为你检出与当前 Kedro 版本匹配的模板如果你希望忽略这种默认行为可以用--checkout显式覆盖例如--checkoutmain。_get_available_tags函数还会通过git ls-remote列出仓库可用 tag在模板未找到时给出提示。使用配置文件配合 Starter默认情况下用 Starter 创建项目时kedro new会交互式地询问project_name并据此自动生成repo_name和python_package——这与 创建新的 Kedro 项目 的默认流程一致。三个变量的含义如下描述配置键示例新项目的人类可读名称project_nameGet Started存放项目的本地目录名repo_nameget-started项目 Python 包名短、全小写python_packageget_started当 Starter 需要的配置项比默认模式更多时可以用--config参数配合一个 YAML 配置文件来非交互式地完成创建uvx kedro new --configmy_kedro_project.yml --starterspaceflights-pandas配置文件中至少需要包含prompts.yml要求的所有键对大多数官方 Starter 而言即project_name、repo_name、python_package。一个可参考的配置示例project_name: Get Started repo_name: get-started python_package: get_started从源码看--config的校验逻辑_fetch_validate_parse_config_from_file与_validate_config_file_against_prompts包含以下几点配置文件必须包含prompts.yml中声明的全部必填键否则报错列出缺失项tools与example_pipeline是可选键缺省时分别使用默认值none与no使用--starter时配置文件中不允许出现tools或example_pipeline键否则直接抛出错误The --starter flag can not be used with example_pipeline and/or tools keys in the config file可选支持output_dir键指定输出目录且该目录必须真实存在project_name会经过正则校验^[\w -]{2,}$只允许字母数字、空格、下划线与连字符且至少 2 个字符。此外_validate_package_name_is_importable会校验最终生成的 Python 包名不能是 Python 关键字如import或标准库模块名如email、json否则项目生成后无法被正确 importkedro run会因ModuleNotFoundError失败。创建自定义 Starter你可以构建自己的 Starter 供项目组或团队内部复用完整操作见 如何创建 Kedro Starter。创建好的自定义 Starter 同样通过--starter使用若是放在一个包含多个模板的仓库中还需要配合--directory指定子目录uvx kedro new --starterpath-to-starter --directory directory一个 Kedro Starter 的本质是一个 Cookiecutter 模板其目录布局大致如下{{ cookiecutter.xxx }}是待 Cookiecutter 替换的占位符{{ cookiecutter.repo_name }} # 模板的父目录 ├── conf # 项目配置文件 ├── data # 本地项目数据不提交到版本控制 ├── docs # 项目文档 ├── notebooks # 项目相关 Jupyter notebook实验代码可先放这里 ├── pyproject.toml ├── README.md ├── requirements.txt ├── src # 项目源代码 │ └── {{ cookiecutter.python_package }} │ ├── __init__.py │ ├── pipelines │ ├── pipeline_registry.py │ ├── __main__.py │ └── settings.py └── tests定制交互式提示prompts.ymlkedro new的交互式问题由模板根目录下的prompts.yml驱动Kedro 内置模板的示例见 kedro/templates/project/prompts.yml包含project_name、tools、example_pipeline三个提示。自定义提示的基本结构如下custom_prompt: title: Prompt title text: | Prompt description that explains to the user what information they should provide.规则与能力每个提示至少必须定义title字段否则kedro new会报错源码中_Prompt类要求title键存在text用于展示问题描述regex_validator用于输入校验error_message用于给出校验失败提示用户输入会作为 CookieCutter 的 extra context 传入因此prompts.yml中的每个键都必须在cookiecutter.json中有对应键Cookiecutter 才能消费这些值默认值可写在cookiecutter.json中参考 kedro/templates/project/cookiecutter.json内含project_name、repo_name、python_package、kedro_version、tools、example_pipeline等键当用户不输入时生效更复杂的校验逻辑可以借助 Cookiecutter 的 pre/post-generate hooks 实现。通过插件入口点扩展 Starter 别名除了本地路径与远程仓库你还可以把自定义 Starter 注册为别名从而直接kedro new --starteryour_starter。做法是在插件中导出一个KedroStarterSpec列表例如仓库中的示例见 features/test_plugin/plugin.py# plugin.py starters [ KedroStarterSpec( aliastest_plugin_starter, template_pathyour_local_directory/starter_folder, ) ]如果模板存放在 Git 仓库中则加上directory指定子目录starters [ KedroStarterSpec( aliastest_plugin_starter, template_pathyour-git-repo-url, directoryspaceflights-pandas, ) ]directory是可选参数用于「一个仓库包含多个模板」的场景官方 kedro-starters 仓库即如此当仓库顶层就是一个模板时无需指定。随后在插件的pyproject.toml中注册入口点可参考 features/test_plugin/pyproject.toml[project.entry-points.kedro.starters] starter plugin:starters完成注册后即可直接使用kedro new --startertest_plugin_starter。自定义别名与官方别名行为一致也会出现在kedro starter list中。底层原理kedro new与 Starter 的协作流程结合 kedro/framework/cli/starters.pykedro new处理 Starter 的完整调用链如下校验参数_validate_flag_inputs检查--directory、--starter、--tools、--example的组合合法性解析模板来源_get_starters_dict返回别名表若--starter命中别名则取出对应template_path/directory并计算默认 checkout若未命中别名则直接把--starter的值当作模板路径若完全没有--starter则回退到内置模板TEMPLATE_PATH定位模板目录_get_cookiecutter_dir通过 Cookiecutter 的determine_repo_dir解析模板——远程仓库会被克隆到临时目录本地路径则直接使用找不到模板时会抛出KedroCliError并附上可用 tag 列表与官方别名清单生成交互上下文_get_prompts_required_and_clear_from_CLI_provided读取模板根目录的prompts.yml把已经由 CLI 提供--name、--tools、--example的键从待提问集合中剔除避免重复提问收集配置有--config则读取并校验配置文件否则按prompts.yml逐个交互提问_fetch_validate_parse_config_from_user_prompts通过_Prompt渲染提示并做正则校验构造 Cookiecutter 参数_make_cookiecutter_args_and_fetch_template把directory映射为 Cookiecutter 的directory参数、checkout映射为其checkout参数最终调用cookiecutter.main.cookiecutter完成渲染_create_project并在成功时打印Congratulations!与项目创建目录。值得注意的是源码中把no_inputTrue与extra_context一起传给 Cookiecutter意味着所有交互输入最终都会被转成 context 字典保证模板渲染全程无需二次交互。相关文档创建新的 Kedro 项目不借助 Starter 的kedro new交互流程与工具选择如何创建 Kedro StarterStarter 模板的完整构建教程与入口点扩展细节spaceflights 教程spaceflights-pandas/spaceflights-pyspark示例项目的配套实战教程安装指南uvx之外的其他 Kedro 安装方式【免费下载链接】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 Starters 使用与自定义指南：用 Cookiecutter 模板快速搭建生产级 Kedro 项目
Kedro Starters 使用与自定义指南用 Cookiecutter 模板快速搭建生产级 Kedro 项目【免费下载链接】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 的 Starter 机制展开讲解如何通过kedro new --starter使用官方或自定义模板创建项目、如何利用别名与--checkout进行版本管理以及如何基于prompts.yml、cookiecutter.json和插件入口点构建团队内部可复用的 Starter。读完本文你将掌握从「选模板建项目」到「写模板并发布为别名」的完整链路并能结合仓库源码理解 Kedro 与 Cookiecutter 的协作方式。什么是 Kedro StarterKedro Starter 是一段以 Cookiecutter 模板形式存在的代码用于生成一个完整的 Kedro 项目骨架。使用 Starter 创建项目就像在使用幻灯片或文档软件时套用一个预设布局Starter 决定新项目包含哪些文件、目录、示例代码和工程化配置而 Cookiecutter 负责把这些占位符替换成你输入的实际值。从源码结构看Kedro 将「模板」与「别名」统一定义为KedroStarterSpec对象kedro/framework/cli/starters.py包含四个字段aliasStarter 的别名出现在kedro starter list中也是kedro new --starter的可选入参template_path模板路径可以是本地目录也可以是 Cookiecutter 支持的远程 VCS 仓库地址directory可选字段当同一仓库内含多个模板时用它指定模板所在子目录origin保留字段由 Kedro 内部用来标记 Starter 的来源官方为kedro插件来源则取插件模块名用户无需提供。Kedro 自身的默认项目模板位于 kedro/templates/project当不指定任何 Starter 时kedro new会使用该内置模板源码中通过TEMPLATE_PATH KEDRO_PATH / templates / project定位。如何使用 Starter 创建项目使用 Starter 创建项目只需给kedro new加上--starter参数uvx kedro new --starterpath-to-starter其中path-to-starter可以是以下三种形式之一本地目录路径由 Cookiecutter 支持的远程 VCS 仓库 URLkedro starter list中列出的别名之一。说明使用uvx可以在不把 Kedro 安装进系统或虚拟环境的情况下运行它——每次调用它都会在一个干净的临时环境中下载并执行 Kedro。如果你更习惯标准安装方式例如 pip 虚拟环境请参考 安装指南。当 Starter 存放在远程 VCS 仓库中且该仓库同时包含多个模板时需要通过--directory指定模板所在子目录uvx kedro new --starter githttps://github.com/kedro-org/kedro-starters.git --directory spaceflights-pandas与 Starter 相关的kedro new参数围绕 Starter 的使用kedro new提供了以下几个核心参数均定义在 kedro/framework/cli/starters.py 的new命令上参数简写作用--starter-s指定要使用的 Starter可以是本地路径、远程 VCS URL 或别名--directory-指定仓库内 Starter 所在子目录仅与--starter搭配使用--checkout-检出 Starter 仓库中的某个 tag、分支或 commit--config-c以 YAML 配置文件方式非交互式提供prompts.yml所需的全部键--name-n直接指定项目名跳过交互式输入--tools-t直接指定项目工具如lint,test、all、none不可与--starter混用--example-e是否包含示例 pipeliney/n不可与--starter混用--telemetry-tc项目创建时登记是否允许收集使用分析yes/no从源码的_validate_flag_inputs可以看到两条关键约束--directory不能脱离--starter单独使用Cannot use the --directory flag without a --starter value--starter不能与--example、--tools混用Cannot use the --starter flag with the --example and/or --tools flag。另外--directory只能用于本地路径或远程仓库形式的 Starter不能与别名搭配——源码中如果检测到starter_alias命中别名表且同时传入了directory会直接抛出Cannot use the --directory flag with a --starter alias错误。因为别名本身已经通过KedroStarterSpec.directory携带了目录信息无需再指定。Starter 别名与kedro starter listKedro 团队为常用官方 Starter 提供了别名使用别名时不必写出完整仓库路径。例如使用spaceflights-pandasStarter 创建项目uvx kedro new --starterspaceflights-pandas查看当前支持的全部别名kedro starter list该命令的实现位于 starter.py 的starter list子命令它聚合所有来源的 Starter 规格按origin分组并以 YAML 形式输出每个别名的template_path与directory。官方 Starter 总是排在输出最前面。别名解析的底层逻辑在_get_starters_dict()中它先从核心仓库内置的_OFFICIAL_STARTER_SPECS_DICT收集官方别名再遍历kedro.starters入口点加载插件声明的 Starter如果插件声明的别名与官方别名冲突插件别名会被忽略并打印警告。也就是说插件完全可以扩展这个别名表。官方 Kedro StartersKedro 团队目前维护以下官方 Starter对应 kedro/framework/cli/starters.py 中的_OFFICIAL_STARTER_SPECS全部存放在官方 kedro-starters 仓库的对应目录下template_path统一指向该仓库directory指向各自的子目录别名说明astro-airflow-iris基于 Iris 数据集的示例项目包含在 Airflow Astronomer 平台上部署 pipeline 的最小配置databricks-iris基于 Iris 数据集的示例项目包含针对 Databricks 部署的配置spaceflights-pandasspaceflights 教程的示例代码数据集基于pandasspaceflights-pysparkspaceflights 教程的示例代码数据集基于pysparksupport-agent-langgraph演示使用 LangGraph 构建 agentic 工作流、并借助 Langfuse 或 Opik 进行提示词管理与追踪的示例项目已归档的 Starters以下 Starter 已归档在 Kedro 0.19.0 及之后版本中不可用standalone-datacatalogpandas-irispyspark-irispyspark最后一个支持这些 Starter 的 Kedro 版本是0.18.14。如果你确实需要它们检查当前安装的 Kedro 版本在终端输入kedro -V安装指定版本例如 0.18.14pip install kedro0.18.14在 0.18.14 下创建项目时同时用--checkout锁定 Starter 版本例如使用pandas-iriskedro new --starterpandas-iris --checkout0.18.14。Starter 版本管理--checkout默认情况下Kedro 使用 Starter 仓库中当前可用的最新版本。若想固定使用某个版本可通过--checkout参数指定uvx kedro new --starterspaceflights-pandas --checkout0.1.0--checkout的值可以是 Starter 仓库中的任意分支branch、标签tag或提交commit。底层实现中该值会被原样传递给 Cookiecutter 的--checkout参数。值得注意的默认行为在 starters.py 的_select_checkout_branch_for_cookiecutter中当使用官方别名且未显式传入--checkout时Kedro 会把当前安装的 Kedro 版本号作为默认 checkout 值。这意味着官方 kedro-starters 仓库按 Kedro 版本打 tag 时会自动为你检出与当前 Kedro 版本匹配的模板如果你希望忽略这种默认行为可以用--checkout显式覆盖例如--checkoutmain。_get_available_tags函数还会通过git ls-remote列出仓库可用 tag在模板未找到时给出提示。使用配置文件配合 Starter默认情况下用 Starter 创建项目时kedro new会交互式地询问project_name并据此自动生成repo_name和python_package——这与 创建新的 Kedro 项目 的默认流程一致。三个变量的含义如下描述配置键示例新项目的人类可读名称project_nameGet Started存放项目的本地目录名repo_nameget-started项目 Python 包名短、全小写python_packageget_started当 Starter 需要的配置项比默认模式更多时可以用--config参数配合一个 YAML 配置文件来非交互式地完成创建uvx kedro new --configmy_kedro_project.yml --starterspaceflights-pandas配置文件中至少需要包含prompts.yml要求的所有键对大多数官方 Starter 而言即project_name、repo_name、python_package。一个可参考的配置示例project_name: Get Started repo_name: get-started python_package: get_started从源码看--config的校验逻辑_fetch_validate_parse_config_from_file与_validate_config_file_against_prompts包含以下几点配置文件必须包含prompts.yml中声明的全部必填键否则报错列出缺失项tools与example_pipeline是可选键缺省时分别使用默认值none与no使用--starter时配置文件中不允许出现tools或example_pipeline键否则直接抛出错误The --starter flag can not be used with example_pipeline and/or tools keys in the config file可选支持output_dir键指定输出目录且该目录必须真实存在project_name会经过正则校验^[\w -]{2,}$只允许字母数字、空格、下划线与连字符且至少 2 个字符。此外_validate_package_name_is_importable会校验最终生成的 Python 包名不能是 Python 关键字如import或标准库模块名如email、json否则项目生成后无法被正确 importkedro run会因ModuleNotFoundError失败。创建自定义 Starter你可以构建自己的 Starter 供项目组或团队内部复用完整操作见 如何创建 Kedro Starter。创建好的自定义 Starter 同样通过--starter使用若是放在一个包含多个模板的仓库中还需要配合--directory指定子目录uvx kedro new --starterpath-to-starter --directory directory一个 Kedro Starter 的本质是一个 Cookiecutter 模板其目录布局大致如下{{ cookiecutter.xxx }}是待 Cookiecutter 替换的占位符{{ cookiecutter.repo_name }} # 模板的父目录 ├── conf # 项目配置文件 ├── data # 本地项目数据不提交到版本控制 ├── docs # 项目文档 ├── notebooks # 项目相关 Jupyter notebook实验代码可先放这里 ├── pyproject.toml ├── README.md ├── requirements.txt ├── src # 项目源代码 │ └── {{ cookiecutter.python_package }} │ ├── __init__.py │ ├── pipelines │ ├── pipeline_registry.py │ ├── __main__.py │ └── settings.py └── tests定制交互式提示prompts.ymlkedro new的交互式问题由模板根目录下的prompts.yml驱动Kedro 内置模板的示例见 kedro/templates/project/prompts.yml包含project_name、tools、example_pipeline三个提示。自定义提示的基本结构如下custom_prompt: title: Prompt title text: | Prompt description that explains to the user what information they should provide.规则与能力每个提示至少必须定义title字段否则kedro new会报错源码中_Prompt类要求title键存在text用于展示问题描述regex_validator用于输入校验error_message用于给出校验失败提示用户输入会作为 CookieCutter 的 extra context 传入因此prompts.yml中的每个键都必须在cookiecutter.json中有对应键Cookiecutter 才能消费这些值默认值可写在cookiecutter.json中参考 kedro/templates/project/cookiecutter.json内含project_name、repo_name、python_package、kedro_version、tools、example_pipeline等键当用户不输入时生效更复杂的校验逻辑可以借助 Cookiecutter 的 pre/post-generate hooks 实现。通过插件入口点扩展 Starter 别名除了本地路径与远程仓库你还可以把自定义 Starter 注册为别名从而直接kedro new --starteryour_starter。做法是在插件中导出一个KedroStarterSpec列表例如仓库中的示例见 features/test_plugin/plugin.py# plugin.py starters [ KedroStarterSpec( aliastest_plugin_starter, template_pathyour_local_directory/starter_folder, ) ]如果模板存放在 Git 仓库中则加上directory指定子目录starters [ KedroStarterSpec( aliastest_plugin_starter, template_pathyour-git-repo-url, directoryspaceflights-pandas, ) ]directory是可选参数用于「一个仓库包含多个模板」的场景官方 kedro-starters 仓库即如此当仓库顶层就是一个模板时无需指定。随后在插件的pyproject.toml中注册入口点可参考 features/test_plugin/pyproject.toml[project.entry-points.kedro.starters] starter plugin:starters完成注册后即可直接使用kedro new --startertest_plugin_starter。自定义别名与官方别名行为一致也会出现在kedro starter list中。底层原理kedro new与 Starter 的协作流程结合 kedro/framework/cli/starters.pykedro new处理 Starter 的完整调用链如下校验参数_validate_flag_inputs检查--directory、--starter、--tools、--example的组合合法性解析模板来源_get_starters_dict返回别名表若--starter命中别名则取出对应template_path/directory并计算默认 checkout若未命中别名则直接把--starter的值当作模板路径若完全没有--starter则回退到内置模板TEMPLATE_PATH定位模板目录_get_cookiecutter_dir通过 Cookiecutter 的determine_repo_dir解析模板——远程仓库会被克隆到临时目录本地路径则直接使用找不到模板时会抛出KedroCliError并附上可用 tag 列表与官方别名清单生成交互上下文_get_prompts_required_and_clear_from_CLI_provided读取模板根目录的prompts.yml把已经由 CLI 提供--name、--tools、--example的键从待提问集合中剔除避免重复提问收集配置有--config则读取并校验配置文件否则按prompts.yml逐个交互提问_fetch_validate_parse_config_from_user_prompts通过_Prompt渲染提示并做正则校验构造 Cookiecutter 参数_make_cookiecutter_args_and_fetch_template把directory映射为 Cookiecutter 的directory参数、checkout映射为其checkout参数最终调用cookiecutter.main.cookiecutter完成渲染_create_project并在成功时打印Congratulations!与项目创建目录。值得注意的是源码中把no_inputTrue与extra_context一起传给 Cookiecutter意味着所有交互输入最终都会被转成 context 字典保证模板渲染全程无需二次交互。相关文档创建新的 Kedro 项目不借助 Starter 的kedro new交互流程与工具选择如何创建 Kedro StarterStarter 模板的完整构建教程与入口点扩展细节spaceflights 教程spaceflights-pandas/spaceflights-pyspark示例项目的配套实战教程安装指南uvx之外的其他 Kedro 安装方式【免费下载链接】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），仅供参考