hey gang new user for the python SDK are there examples of g

Question

hey gang new user for the python SDK are there examples of good patterns for mocking remote tasks workflows a la what `task mock` can do for local python tasks While I can get local patching working sometimes it runs into issues e g with explicit task dependencies set like `t1 gt gt t2 ` where the return value mocked as a python type is missing some flyte node plumbing under the hood

Yee · Answer

do you have repros you can copy paste please

Yee · Answer

we ll make a ticket out of it and work on it

Yee · Answer

it should work and even if there are cases where they don t we need to improve our error messaging to explain why

John Walk · Answer

Untitled py

John Walk · Answer

hmm might be harder cause the remotes are all from our internal task warehouse but basically the setup goes like point up

John Walk · Answer

for testing the guidance from our ML infra team was to just patch out the return values to their python types

John Walk · Answer

Untitled py

John Walk · Answer

when the remotes return values and done use the ` rshift ` logic it seemingly works ok though the patches are pretty sensitive to imports in the test but the above fails with an assertion error

John Walk · Answer

that `None` lacks the `ref` attribute needed to actually build the DAG

John Walk · Answer

gt it should work and even if there are cases where they don t we need to improve our error messaging to explain why I suspect the issue is actually in our guidance for how to mock these tbh

John Walk · Answer

< Yee> looking at this some more I wonder if the problem isn t how that `handle` function is built in our internal libraries it looks like the `RemoteEntity` returned by `fetch task` should work with `flytekit testing patch` right

Yee · Answer

yes it should

Yee · Answer

let me spend some time today looking

John Walk · Answer

yeah I think we have one too many layers of abstraction where our internal lib s wrappers are returning the result of calling the RemoteEntity rather than returning the entity itself which then would work with the patching

Yee · Answer

let me get the patching working for remote entities first demonstrate that basic unit tests work

John Walk · Answer

+1

Yee · Answer

< John Walk> reviewed the testing code in flytekit it does look like it s built currently just for non fetched tasks but i m not sure that really matters

Yee · Answer

i ll add an example of how you might test a fetched task <https github com flyteorg flytekit pull 1722 files>

Yee · Answer

you can avoid using the testing stuff in flytekit completely

Yee · Answer

see the `test mocking remote` test

John Walk · Answer

ok yeah that squares with my thinking we ve just got the actual remote task buried under one too many layers of abstraction

John Walk · Answer

reckon I could try building a patcher functionality for our wrappers using the logic you ve got there

John Walk · Answer

ok yeah I was able to get it working with patching `fetch remote` within our internals but that required defining a mock task with matching kwargs for each remote task which is a little gnarly

John Walk · Answer

would be nicer if we could find a way to `task mock` the RemoteEntity it grabs like you ve got in yours

John Walk · Answer

hah actually seems like we get the same effect if we just make a mock task and set that as a side effect of the mocked parent function same problem with the expected arguments though

Yee · Answer

yeah there s no way around the expected arguments that feeds the interface and the interface needs to be correctly defined

Yee · Answer

we ll merge that pr today

John Walk · Answer

gt that feeds the interface and the interface needs to be correctly defined yeah unless we can get at mocking the internal RemoteEntity reckon we re stuck with it