Framework Redesign

[yetudada]

Description

We introduced KedroContext last year to orchestrate many things in Kedro and give users a way to extend or override certain functionalities in Kedro.

However, we've received a lot of feedback about KedroContext, some identified problems include:

• It's challenging to identify which code you should be modifying in KedroContext
• We've also included workarounds that users have called out in [KED-1169] Library code should be framework decision agnostic #149, and through tangential issues in [KED-1258] Allow logging directory to be specified #161

Context

We care about this issue because:

• We want to be able to create a clear framework for building extensions and modifying program behavior.
• We also believe that this change can help us address issues surrounding the pain of upgrading the Kedro project to the latest version.
• You'll also be able to build plugins that can do so much more when they interact with Kedro.
• It has implications for how successfully we're able to deliver Modular Pipelines and some of the insane modifications that are coming to kedro-viz.

Possible Implementation

We're currently mapping out user journeys and are considering tools like pluggy, as a way of providing hooks for you to modify Kedro. pluggy manages the plugins and hook calling for pytest and is a popular tool. Do let us know if you're aware of any other tools that we could look at.

Next steps

We're watching issues like #149 but comment below with any more feedback you have about KedroContext.

[yetudada]

We launched the following features documented in these PRs:

• [KED-1169] Library code should be framework decision agnostic #149 (clear separation between the library and framework of Kedro)
• [KED-1258] Allow logging directory to be specified #161
• src_prefix is not configurable #379