Add Dask as an execution target
I dont see anything to object with here, i think its safe to button it up a bit and get it ready to land
|97 ↗||(On Diff #898)|
well need a SolidHandle.from_id() or some such that splits on the . and reconstructs the parent hierarchy
|79 ↗||(On Diff #864)|
ya we should be able to set up a test that ensures we have an example event for every entry in the event type enum, and that each of those examples can round trip through graphql correctly.
It might make sense to have a central GraphQL fragment that different executors can include in their query to ensure all the fields the centralized parser will need to reconstruct.
|310–355 ↗||(On Diff #898)|
good call, updated
I might pick up https://github.com/dagster-io/dagster/issues/1379 and take care of this by flipping to a consolidated API that uses pipeline run storage, vs. trying to hack this into executePlan
you can use startPipelineExecution instead of executePlan in this test if that gives you run storage - as long as we are using the same fragment it should not matter which mutation we use
i wonder if we should factor out the common stuff between this and dagster-airflow for a common out-of-process toolkit
strong reason not to use the namedtuple pattern we often follow?
hmmm, 0.0.0.0? this seems brittle but if we're just using it for a seatbelt, ok
did this name change?