-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documenting "inspect" and context awareness udf.rst #617
base: master
Are you sure you want to change the base?
Conversation
Hi, I made a quick description on how to use the "inspect" function to print within the UDFs. moreover, I tried to give a brief explanation on how users can provide their own local side variables to be used within the UDF.
Nice, thanks! |
Hi, thanks for taking the time to contribute! About the part on About the part on passing through the context: that is indeed a valid topic to document better. Also see the discussion at #520 |
Yes, indeed it is better to integrate into the existing docs. |
good point, it's not easy to find succint examples on properly using context in UDF. We have some unit test coverage in the VITO backend on this for example at https://github.com/Open-EO/openeo-geopyspark-driver/blob/cdd731ce6d684eba894beff7c8ac78266ddf12b0/tests/test_api_result.py#L718-L889, but that's probably a bit cryptic. I think there are two use cases to document:
udf = openeo.UDF(
"...",
context={"factor": 12.34},
)
cube = cube.apply(udf)
udf = openeo.UDF(
"...",
context={"from_parameter": "context"},
)
cube = cube.apply(udf, context={"factor": 12.34}) Both of these patterns have their usefulness .The first is simpler to reason about. The second is the approach to take when the context comes from "higher up", e.g. UDP parameters |
That being said, I think the python client should make it simpler to get that second usage pattern right. I made a ticket for that: |
Co-authored-by: Stefaan Lippens <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added proper description, shorter lines and passing "context" to parent udf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some more notes
======================================== | ||
|
||
In order to pass variables and values that are used throughout the user side of script, these need to be put in the `context` dictionary. | ||
Once, these variables are defined within `context` dictionary, the UDF needs to be made context aware, by adding `context={"from_parameter": "context"}` at the end of your UDF. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once, these variables are defined within `context` dictionary, the UDF needs to be made context aware, by adding `context={"from_parameter": "context"}` at the end of your UDF. | |
Once these variables are defined within `context` dictionary, the UDF needs to be made context aware, by adding `context={"from_parameter": "context"}` at the end of your UDF. |
variables are defined within
context
dictionary
This is a bit confusing, because in your example you define them in a user_variable
dictionary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true, how should I define it?
Co-authored-by: Stefaan Lippens <[email protected]>
Hi, I made a quick description on how to use the "inspect" function to print within the UDFs.
moreover, I tried to give a brief explanation on how users can provide their own local side variables to be used within the UDF.