It would be nice to get some clarity in the docs f...
# dagster-feedback
l
It would be nice to get some clarity in the docs for using non-argument dependencies in graph-backed assets. The
@graph_asset
decorator takes an
ins
mapping like ops, but with
AssetIn
instead of
In
. Since
AssetIn
won't take
Nothing
, you have to add the key to the decorated function's arguments, but then you also have to pass that argument to something, like the first op, which has no dependencies. The result is a bunch of bits and pieces that behave like both ops and assets, with the clarity of neither. For example, this looks to be the cleanest way to define non-arg deps for graph-back assets:
Copy code
@graph_asset(ins={'upstream_asset': AssetIn('upstream_asset')})
def example_graph_definition(upstream_asset: None):
    last_op(first_op(upstream_asset))
where
Copy code
@op(ins={'start': In(Nothing)})
def first_op():
    do_something()
    return
This is quite difficult to explain to others. Would love to see this instead, with all the wiring between ops and graphs and assets done behind the scenes:
Copy code
@graph_asset(non_argument_deps={'upstream_asset'})
def example_graph_definition():
    last_op(first_op())
where
Copy code
@op
def first_op():
    do_something()
    return
Is there a better way to do this without crossing the assets/ops paradigm barrier?
Some of the Dagster magic is there - you don't have to give the
@graph_asset
decorator anything and the asset key is inferred from the function argument, but to know that it's a nothing dependency you have to find the op definitions.