[KEP-3] Optional @node decorator to reduce Kedro boilerplate

[DimedS]

Related issue: #5360
Additional discussion (alternative decorator syntaxes): #5028
KEP shepherd: @DimedS

Q1. What are we trying to do?

Introduce an optional @node decorator that lets users declare Kedro nodes directly on Python functions, reducing the boilerplate of manually wiring Node() and Pipeline() for simple cases—while keeping existing APIs fully supported.

Q2. What problem is this proposal NOT designed to solve?

• This is not a replacement for the current node() / Pipeline() APIs.
• This is not aiming to remove pipeline_registry.py or enforce auto-discovery for all projects.
• This is not trying to support every advanced use case (e.g. complex reuse patterns, dynamic pipelines) on day one.

Q3. How is it done today, and what are the limits of current practice?

Today users typically:

• define functions in nodes.py
• wire them into Node(...) objects and Pipeline([...]) in pipelines.py
• register pipelines in pipeline_registry.py

This is explicit and scalable, but can feel heavy for quick iteration and small pipelines, especially for new users coming from scripts/notebooks.

Q4. What is new in your approach and why do you think it will be successful?

Add a decorator-based path as syntactic sugar for common/simple workflows, e.g.:

@node(inputs="raw_data", outputs="filtered_data", pipeline="data_engineering")
def filter_data(df):
    ...

Kedro can then discover decorated functions and build pipelines automatically (or semi-automatically). This should speed up iteration without taking away the explicit path that teams rely on for larger projects.

Q5. Who cares? If you are successful, what difference will it make?

• New users / notebook-first users: quicker first success, less “where do I put what?” friction.
• Teams prototyping pipelines: less scaffolding when exploring ideas.
• Maintainability: optional, explicit metadata (inputs/outputs/pipeline) can preserve clarity while reducing file hopping.

Q6. What are the risks?

• Two ways to do the same thing could create confusion and documentation burden.
• Function reuse across multiple nodes/pipelines may become awkward depending on the chosen design.
• Integration surface area: interaction with namespaces, hooks, CLI selection, and Kedro-Viz must remain predictable.

Q7. How long will it take?

Spike / PoC: ~1–2 weeks to prove feasibility and clarify design trade-offs.

Q8. What are the mid-term and final "exams" to check for success?

Mid-term

• A minimal PoC demonstrating @node and pipeline construction for a simple pipeline
• Clear written assessment of feasibility, constraints, and integration points (CLI, pipeline registry, viz)

Final

• Decision recommendation: proceed / iterate / stop
• If proceeding: an experimental implementation behind clear documentation and guardrails, plus user feedback signal

Please vote +1/-1 in comments, not the pool!

[deepyaman]

+1

I think it's worth building off the final PoC in #5028 (comment) and/or what another user shared below that.

[datajoelypx]

I personally do not see value in adopting this unless we have conviction in replacing the existing method

[deepyaman]

I largely agree, but I'm of the opinion that it should become the predominant method, potentially barring especially complex cases (e.g. dynamic pipelines). I think this is aligned with how other popular frameworks operate, where you may have to drop down into "lower-level" constructs to express dynamic dependencies, etc.

[DimedS]

I agree - if we go in this direction, we should do it with the conviction that this becomes the main and recommended approach over time. The legacy method could remain as an option for a transition period, but eventually it should be phased out if the new approach proves itself.

[rashidakanchwala]

+1 Interested in this feature; let’s proceed with a spike

[deepyaman]

My opinion: #5378 (reply in thread)

[merelcht]

I feel like this adds ambiguity in how to do things and removes clarity & opinion of how to build Kedro pipelines, potentially adding more to the already steep learning curve. I don't want to block any spikes here, so I'll abstain from voting.

[DimedS]

As @datajoelypx mentioned, I think the spike should explicitly validate that the new approach is feasible, more elegant, simpler, and provides at least the same capabilities as the current one. If that proves true, then it should become our main and recommended way to declare pipelines - and in that case, it would actually reduce the learning curve rather than increase it.

[deepyaman]

I don't want to block any spikes here, so I'll abstain from voting.

I don't think we need a vote or anything to pursue a spike; it sounds like it would be worth doing that and voting on an updated proposal for introducing this feature in core?

[SajidAlamQB]

I have some reservations about the feature itself. Kedro principles is usually aligned towards simplicity, with small number of parts and very little optionality. We intentionally separate pure functions from pipeline management which I think is one of Kedro's best design decisions. It lets you reuse the same function across pipelines with different inputs/outputs so I'm wondering how the decorator preserves this without making things awkward.

[rashidakanchwala]

that's a very good point.

[DimedS]

It’s a fair point - I think it would be great if we investigate options to overcome that problem as part of the spike.

[deepyaman]

We intentionally separate pure functions from pipeline management which I think is one of Kedro's best design decisions. It lets you reuse the same function across pipelines with different inputs/outputs so I'm wondering how the decorator preserves this without making things awkward.

This is exactly why I went from something akin to what @DimedS has in the proposal above to not including the inputs/outputs as part of the node decorator; you can see the iterations in #5028 (comment). In the end state, nodes are simply decorated vanilla functions, and the pipeline piece is a more Pythonic alternative to what Kedro currently provides. Similarly, the work @pierrejeden shared in #5028 (reply in thread) also keeps inputs/outputs out of the decorator definitions.

[ravi-kumar-pilla]

+1 I am up for the spike and POC. I would love to see this design evolve and become the new default.

Rationale

1. Based on my recent experience with CrewAI which uses decorators and also provides a traditional way of doing things, Kedro can also support such a pattern and make development easy
2. Another recent spike work for inspection which was facing issues with dependencies as we cannot fully rely on AST, I see a possibility of using AST in future where everyone is using the decorator approach and inspection can just use AST and get these decorator declarations to inspect a kedro project
3. Though using decorators feels non trivial (as is the case with anything new), it is worth spending time on a spike to investigate if this approach can evolve and cater for complex use-cases and not just simple functions. It would not be worth having this change come in with fast limitations on the complexity it can handle.

Thank you

[DimedS]

We are closing this KEP. We have +3 votes and no -1, so we will proceed with the spike in #5360, incorporating the comments raised in the current discussion.

Thank you everyone for your participation.