Kaxil Naik

> Good point! This PR only affects provider docs. Task SDK docs use different config (`autoapi_generate_api_docs = False`) so they should still work. You need to confirm it works as...

Yeah it is in an issue. The problem is the dag is already parsed before the `dag.test` code can be called which would assign `task_runner.SUPERVISOR_COMMS = InProcessSupervisorComms`

> Assuming we can detect the case when this is being imported from doing `python mydag.py` (which I'm 95% sure we can, so that is the 'easy' part) how should...

@opeida The ideal way would be to not access Variables or Connections at the top of your file (i.e outside Task Context). In your case, you can rewrite the dag...

You can just do following in your case: ```py provider_name = "" def my_function(my_var: str) -> None: logging.getLogger(__name__).info(my_var) with DAG("test_dag") as dag: start = EmptyOperator(task_id="start") py_func = PythonOperator( task_id="py_func", python_callable=my_function,...

> So: detecting when we have top-level dag code, at least in the `python mydagfile.py` case: > > def __getattr__(name): > if name == "SUPERVISOR_COMMS" and "__main__" in sys.modules: >...

> We use variables for dynamic DAG scheduling, so we can access and modify schedules via web-UI by ourselves, without having to change deployment configs (OS environment variables) through DevOps...

cc @SHASHI9705

> Hi @kaxil , apologies for the delay,I was tied up with my exams. > Thanks for the mention. I’ve started looking into this and will share an update soon....

@Dev-iL Could I assign this GitHub issue to you? You can the lead the "scoping" part of this epic by talking to Jarek and others on Slack, mailing list and...