Kedro: [KED-1537] Allow a node input to be a literal value.

[sansagara]

I think kedro should add the way to pass a literal to a node, just like they did with param:.
Maybe something like literal: or string: and int:

__Originally posted by @sansagara in https://github.com/quantumblacklabs/kedro/issues/213#issuecomment-698932788__

[WaylonWalker]

This would make things simpler, but it is currently possible using partial or lambda functions. See my comment on the previous issue https://github.com/quantumblacklabs/kedro/issues/213#issuecomment-699509279.

If this were implemented I would fear that it would make doing bad things too easy. The current design makes doing the right thing easy (loading from the catalog or params) and doing borderline things possible. I would hate to see a pipeline completely bypass the catalog and pass DataFrames directly into the node.

[921kiyo]

Hi! Thanks for the feature request. This has been requested several times, and we are looking into it :)

[Galileo-Galilei]

Hello,

*Disclaimer to the OP: Sorry for the downvote, it is the only way to say that I am against implementing this feature but no offense intended, it is absolutely not personal.

I totally support @WaylonWalker point of view here for everal reasons:

• I understand why someone want to do this (mainly to iterate faster during their exploration phase), but this will very encourage bad software engineering practice (i.e. tighten compute and configuration by not using a conf file).
• I know it sounds a bit harsh but I don't think this feature request is in line with Kedro's principles (i.e. enforces SE best practices as much as possible).
• Since the little hack with lamba suggested by @WaylonWalker already works well, I don't feel it would improve much user experience.
• This feature will also prevent to track the parameter with a specific name, for logging in mlflow for instance (ok this one is self interested 😇)

[sansagara]

Hello,

*Disclaimer to the OP: Sorry for the downvote, it is the only way to say that I am against implementing this feature but no offense intended, it is absolutely not personal.

I totally support @WaylonWalker point of view here for everal reasons:

• I understand why someone want to do this (mainly to iterate faster during their exploration phase), but this will very encourage bad software engineering practice (i.e. tighten compute and configuration by not using a conf file).

• I know it sounds a bit harsh but I don't think this feature request is in line with Kedro's principles (i.e. enforces SE best practices as much as possible).

• Since the little hack with lamba suggested by @WaylonWalker already works well, I don't feel it would improve much user experience.

• This feature will also prevent to track the parameter with a specific name, for logging in mlflow for instance (ok this one is self interested 😇)

I kinda disagree here. Not everything needs to be in a config file. Specially if it's a simple literal like a short string. I see no value in creating a new config file entry for something where the key is longer than the value (and it's not repeated/reused).

Also, i would think that since there's already
params:, adding lit: is not going to add much overhead?

While i certainly respect the fact that you are trying to take the library into the direction you envision, at the end it's about possibilities. And IMHO Kedro (as well as any other Open Source library) should encourage, but not limit any kind of practice.

In any case, feel free to discard if not on your roadmap/plans.

[Minyus]

I understand opinions/motivations from both sides.

I personally would like QuantumBlack team to prioritize other tasks (Kedro has exciting product roadmap!) as this feature would consume a lot of labor cost for especially preparing testing code and documentation even if we already have a "solution" as suggested by @WaylonWalker.

Having said that, some users might feel it is not a straightforward solution.

I would suggest highly motivated users (rather than QB team) prepare testing code and draft documentation to ensure @Galileo-Galilei 's concerns are addressed before QB team starts to design the solution.

[lorenabalan]

Thanks everyone for weighing in. An update on this is that we did try to prototype a solution (using a literal() wrapper rather than a lit: prefix) but it quickly turned into a rabbit hole so it's been parked for a later revisit. We're being very careful about this feature, as we mirror the same concerns expressed in this thread - i.e bypassing configuration or confusing API (when do you use config vs in-line code).