Skip to content
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

Add run_process #307

Draft
wants to merge 2 commits into
base: draft
Choose a base branch
from
Draft

Add run_process #307

wants to merge 2 commits into from

Conversation

m-mohr
Copy link
Member

@m-mohr m-mohr commented Nov 23, 2021

Proposal for solving Open-EO/openeo-api#413 in a non-breaking way.

Similar functions in other programming languages:

@jdries
Copy link
Contributor

jdries commented Nov 24, 2021

See comment on other issue: currently not in favor of this as a solution to avoid allowing parameters for process_id.

Copy link
Contributor

@dthiex dthiex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look okay to us.

@soxofaan
Copy link
Member

soxofaan commented Dec 8, 2021

a devil's advocate argument against this process: I think you lose the ability to statically check/validate your process graph because the output schema of run_process is only known at run time.

This might be annoying in several places: visualization of process graph (e.g. in web editor), in clients that use output schemas to help building a process graph , the /validation end point, the dry-run procedure in the geopyspark driver, ...

@m-mohr
Copy link
Member Author

m-mohr commented Dec 8, 2021

This might be annoying in several places: visualization of process graph (e.g. in web editor), in clients that use output schemas to help building a process graph , the /validation end point, the dry-run procedure in the geopyspark driver, ...

Yes, but checking it in the JS tooling shows that this is equally annoying as allowing variable for process_id. It is basically the same implementation-wise, just a different encoding.

@m-mohr m-mohr marked this pull request as draft February 23, 2022 12:59
@m-mohr m-mohr modified the milestones: 1.3.0, 2.0.0, future Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants