I don't know what it would take under the hood, but I'm intrigued. From a user perspective, anything to make the DAG DRYer is a win IMHO.
________________________________________ From: Malthe <[email protected]> Sent: Wednesday, April 27, 2022 1:49 AM To: [email protected] Subject: [EXTERNAL] Implicit DAG registration CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. DAGs must be registered at the module top-level. During dagbag processing we have: top_level_dags = ((o, m) for m in mods for o in m.__dict__.values() if isinstance(o, DAG)) It makes sense of course – we can't have DAGs floating in space, they need an anchor. Or do they? It would be entirely possible for the DAG constructor to register itself with some global registry, obviating for the follow pattern: with DAG(...) as dag: ... I think most users would prefer: with DAG(...): ... Since there is generally speaking no need for the alias. Downsides? You have less control of what DAGs are made available – but really, does it make sense to create a DAG object only to drop it immediately after? I volunteer to implement this if there's a positive feedback. Cheers
