Hello All, Wishing you all a happy new year and hope you spent good time with your loved ones.
With the ongoing efforts on Airflow Client Server separation, I figured that this would be a good time to discuss a proposal in a similar vein to those efforts. I'd like to propose establishing an `airflow.core.*` module namespace for server-only components as part of our AIP-72 client-server separation work. *What:* Move server-specific modules(API, scheduler, migrations, ORMs, and more) that are specifically used by the server components, to a new `airflow.core.*` namespace. For example: - airflow.models.* → airflow.core.models.* - airflow.jobs.* → airflow.core.jobs.* - airflow.api_fastapi.* → airflow.core.api.* (or retain `api_fastapi`) Backward compatibility would be maintained for the older paths with some tooling that we already have <https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/utils/deprecation_tools.py> by issuing deprecation warnings and providing users with a clear migration path. *Why:* AIP-72 separates airflow into server and client components, but today there is no way to tell from an import path whether the code is intended to be server only or client only, or shared(shared is still better). This makes it easy to accidentally couple components that should be independent. We have some prek hooks in place to avoid this as much as possible, but there is a limit to how much we can restrict. Moving the server code to `airflow.core.*` would make the boundary much clearer. The end goal would look like: - airflow.core.* = server-only - airflow.sdk.* = client-side - airflow._shared.* = shared between both It would also bring in some added benefits: 1. Self documenting architecture: the import paths would now reveal dependencies between components 2. Reduced accidental coupling We already have two issues in place to track this: 1. https://github.com/apache/airflow/issues/51554 2. https://github.com/apache/airflow/issues/51555 I have deliberately not listed the estimate of efforts here to agree on the approach first. I would love to hear what folks think about this approach until Saturday: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Voting+ends&iso=20260110T0830&p1=1440 and will start a lazy consensus after that. Thanks & Regards, Amogh Desai
