Andrushika opened a new pull request, #76909: URL: https://github.com/apache/airflow/pull/76909
This is a draft to agree on the approach first. I would like feedback on the shape of the entry-point init, mainly the open questions at the end, not a merge yet. Once the approach looks right, I will mark it ready. It is safe to merge before part 3 of the plan, because it changes no behaviour. ## Why `airflow/__init__.py` calls `settings.initialize()` when anything imports `airflow`. This is the only call in the repo. It sets up config, logging, plugins and the metadata DB engine. So every entry point depends on the import to do this work, and every user who only imports a Dag pays for it too. The dev@ thread [Faster `import airflow`](https://lists.apache.org/thread/1nhdc8y1x7dclcpcck98q5chzh1tvodk) proposes that the import stops doing this, and that the entry points call a new function instead. If we remove the call today, the entry points break. With `_AIRFLOW__AS_LIBRARY=1`, which skips that call, 9 of 14 CLI checks fail on main and the API server does not start. ## What Add `settings.ensure_initialized()`, which runs `initialize()` once per process. Five entry points now call it: the `airflow` CLI, `api_fastapi/main.py`, `dag.test()`, the posix_spawn child in the supervisor, and `execute_workload`. The last two pass `orm=False` because task processes must not use the metadata DB. While `airflow/__init__.py` still initializes, each new call does nothing, so behaviour does not change. With `_AIRFLOW__AS_LIBRARY=1`, all 14 checks pass and two Dag runs succeed in a real `airflow standalone`. One side effect: `_AIRFLOW__AS_LIBRARY` no longer skips the init in these five entry points. Only tests and schema scripts set it. The supervisor child already initializes core today through `import airflow`. The new call makes this explicit, and it skips the call when core is not installed. ## Plan This is part 1 of 3. Part 2 does not depend on this PR and can be reviewed on its own. 1. This PR: entry points initialize themselves. No behaviour change. 2. #<A1> and #<A2>: the SDK stops loading core while it builds a Dag. No behaviour change for normal setups. 3. Later: `airflow/__init__.py` stops calling `initialize()`. This needs a compatibility plan for code that imports core directly. On a branch with all three parts, a small Dag file runs in 447ms instead of 768ms. A pytest that imports it takes 569ms instead of 934ms. I am working on all three parts. If you want to help with this, please comment here or on the dev@ thread first, so we do not duplicate work. Open questions: - The name and home of `ensure_initialized`. It would move together with the code if core moves to `airflow.core`. - One function with an `orm` flag, or separate pieces per entry point. Today only the ORM part has an entry point that does not need it. related: https://lists.apache.org/thread/1nhdc8y1x7dclcpcck98q5chzh1tvodk --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (please specify the tool below) Generated-by: Claude Code (Opus 5.5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
