This diff simplifies the two base airflow operators we use, in advance of implementing correct Airflow task skip behavior when a step skip event is returned by Dagster step execution
is it just oop pedantry that makes me prefer even a no-op DagsterOperator abc?
do we prefer this to the operators having a single interface and then throwing away the args they don't consume?
Just noting that this landed in https://github.com/apache/airflow/pull/5369. I think we should consider vendoring the DockerOperator and PythonOperator to improve our Airlflow backwards compatibility and reduce the need for shims like this
conceivably we should introduce a stronger check, since we can have storage: in_memory:, which won't work for airflow
I started by leaving it, but that forces you into multiple inheritance since I can't put DagsterOperator between both DockerOperator and PythonOperator - maybe the right way to solve this is to inherit from DagsterOperator in our vendored versions of those, which would especially be nice to ensure we distinguish from the built-in Airflow versions of those.
I think so - I started w/ the other and it felt a little gross to dance around what gets routed through kwargs vs named params. but def willing to play around a bit more, maybe there's another way to structure this
ha, that's funny. yeah I like the idea of vendoring, maybe a good follow-up
good call, I added a check for this