Provider Catalog & Connections

DagSmith doesn't ship a hand-maintained list of operator blocks. Instead, it introspects whatever Airflow providers are actually installed in your environment via ProvidersManager, and builds the palette from that.

How a block's parameter form is built

• Every BaseOperator subclass exposed by an installed provider becomes a block.
• Its parameter form comes from the __init__ signature — walked across the class hierarchy (MRO) for operators that forward **kwargs to a parent (common in SQL-family operators like Teradata or Snowflake, which forward sql, parameters, etc. to a shared base class).
• Simple types (str, int, bool, literals, dict) get a matching typed editor; anything else becomes a raw-Python expression field, validated with ast at codegen time and round-tripped as source text.

The catalog is cached (configurable TTL) and served with an ETag, so the palette stays fast even with hundreds of blocks across dozens of providers.

Connection picker

Any parameter named like *conn_id renders as a dropdown populated from your Airflow connections — read directly from the connection table (and AIRFLOW_CONN_* environment variables), never through an Airflow ORM session. Connections whose type matches the parameter's prefix (e.g. teradata_conn_id → teradata) are sorted first. Free text stays allowed, since secrets-backend connections aren't enumerable this way.