Katalog providerów i połączenia

DagSmith nie ma ręcznie utrzymywanej listy bloków operatorów. Zamiast tego introspektuje, jakie providery Airflow są faktycznie zainstalowane w Twoim środowisku, przez ProvidersManager, i na tej podstawie buduje paletę.

Jak powstaje formularz parametrów bloku

• Każda podklasa BaseOperator udostępniana przez zainstalowany provider staje się blokiem.
• Jej formularz parametrów pochodzi z sygnatury __init__ — przechodzonej przez całą hierarchię klas (MRO) dla operatorów, które przekazują **kwargs do rodzica (częste w rodzinie operatorów SQL, jak Teradata czy Snowflake, przekazujących sql, parameters itd. do wspólnej klasy bazowej).
• Proste typy (str, int, bool, literały, dict) dostają dopasowany, typowany edytor; wszystko inne staje się polem z surowym wyrażeniem Pythona, walidowanym przez ast przy generowaniu kodu i odtwarzanym jako tekst źródłowy przez parser.

Katalog jest cache'owany (konfigurowalny TTL) i serwowany z ETagiem, więc paleta zostaje szybka nawet przy setkach bloków z kilkudziesięciu providerów.

Wybór połączeń (connection picker)

Każdy parametr nazwany jak *conn_id renderuje się jako lista rozwijana wypełniona Twoimi połączeniami Airflow — czytanymi bezpośrednio z tabeli connection (oraz ze zmiennych środowiskowych AIRFLOW_CONN_*), nigdy przez sesję ORM Airflow. Połączenia, których typ pasuje do prefiksu parametru (np. teradata_conn_id → teradata), są sortowane na górze. Wolny tekst dalej jest dozwolony, bo połączeń z secrets-backendu nie da się w ten sposób wyliczyć.