@Scout is there a way to declare assets with dependents instead of dependencies?

In Dagster, assets are typically defined with dependencies, specifying which assets they depend on to compute their value. However, the concept of declaring assets with dependents (i.e., specifying which assets are downstream of a given asset) is not directly supported in the same way. The standard way to define dependencies is by using the

deps

parameter in the

@asset

decorator to specify upstream assets. This creates a clear lineage from upstream to downstream assets, which Dagster uses to determine execution order and to display lineage information in the UI. Here's an example from the documentation on how to define an asset with dependencies:

python from dagster import asset  @asset def sugary_cereals() -> None:     # logic to create sugary_cereals asset     ...  @asset(deps=[sugary_cereals]) def shopping_list() -> None:     # logic to create shopping_list asset, which depends on sugary_cereals     ...

In this example,

shopping_list

is defined as depending on

sugary_cereals

. Dagster does not provide a built-in way to invert this relationship and declare

sugary_cereals

as having

shopping_list

as a dependent directly in the asset definition. However, dependencies are inherently a two-way relationship: if

shopping_list

depends on

sugary_cereals

, then

sugary_cereals

is a dependency of

shopping_list

. While Dagster's API is designed to specify dependencies from the perspective of the downstream asset, the system understands and manages these relationships bidirectionally under the hood. If you need to track dependents for a particular use case, you would typically need to do this outside of the asset definitions, perhaps by maintaining a separate mapping or using naming conventions that make the relationships clear. Dagster's asset graph and lineage tools in the UI can help visualize these relationships based on the defined dependencies.

@Scout is there a way to define dependencies outside of the asset definition? maybe in the Definitions object?

Yes, Dagster allows you to define dependencies outside of the asset definition using the

Definitions

object. This can be particularly useful when dealing with external assets or when you want to define dependencies separately from the asset's implementation. For external assets, which are assets not materialized by Dagster but tracked in the asset graph and asset catalog, you can use

external_assets_from_specs

to create an external assets definition from a sequence of

AssetSpec

objects. Here's an example from the documentation:

python from dagster import AssetSpec, Definitions, external_assets_from_specs  raw_logs = AssetSpec("raw_logs") processed_logs = AssetSpec("processed_logs", deps=[raw_logs])  defs = Definitions(assets=external_assets_from_specs([raw_logs, processed_logs]))

In this example,

processed_logs

is defined as having a dependency on

raw_logs

outside of the asset definition itself. For software-defined assets, you can define dependencies using the

deps

parameter within the

@asset

decorator, as shown in the previous examples. However, if you want to define dependencies separately, you might consider using Dagster's graph-based APIs, where you can define dependencies between ops within a graph, and then create assets from that graph. This allows you to define the execution logic and dependencies separately from the asset definitions. Here's an example of how you might define dependencies within a graph and then create assets from that graph:

python from dagster import op, graph, GraphOut, AssetsDefinition  @op def make_asset1():     ...  @op def make_asset2(asset1):     ...  @graph(out={"asset1": GraphOut(), "asset2": GraphOut()}) def make_assets():     asset1 = make_asset1()     return asset1, make_asset2(asset1)  assets = AssetsDefinition.from_graph(make_assets)

In this example,

make_assets

is a graph that defines the dependencies between

make_asset1

and

make_asset2

. The

AssetsDefinition.from_graph

method is then used to create assets from this graph, with the dependencies defined within the graph being preserved in the resulting assets. Please note that the specific APIs and methods available may evolve over time, so it's always a good idea to check the latest Dagster documentation for the most up-to-date information on defining dependencies and working with assets.