Open-EO / Open-EO/openeo-python-client
Context parameter in openeo.UDF.from_file() causes confusion
Open
Nobody has claimed this yet.
api compliancy
documentation
feature request
nice-to-have
usability
- Dominant language
- Python
- Stars
- 217
- Forks
- 56
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 2
Description
A user let us know that the following code does not pass the context to his UDF:
cube = cube.apply_neighborhood(
openeo.UDF.from_file("test_udf.py"),
size=[
{"dimension": "x", "unit": "px", "value": 32},
{"dimension": "y", "unit": "px", "value": 32}
],
overlap=[],
context={"test_variable": "Definitely not None"}
)
The solution was to pass the context in the from_file method instead:
cube = cube.apply_neighborhood(
openeo.UDF.from_file("test_udf.py", context={"test_variable": "Definitely not None"}),
size=[
{"dimension": "x", "unit": "px", "value": 32},
{"dimension": "y", "unit": "px", "value": 32}
],
overlap=[],
)
We should either:
- Make it clear that the context parameter should not be used when an UDF object is passed
- Merge the two context parameters in the process graph
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing openeo.UDF.from_file() and apply_neighborhood() to see how each context parameter enters the process graph. Check the generated graph for the example in the issue; done when the context behavior is made unambiguous and the two stated usage patterns are either documented clearly or handled consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100