+1 to this. Clear namespace boundaries will definitely help folks understand what depends on what. Agree with Jens on organizing by server component too.
Regards, Rahul Vats On Mon, 5 Jan 2026 at 14:02, Jens Scheffler <[email protected]> wrote: > Hallo Amogh, > > that totally makes sense to get the "house clean" and separate. > > If we are moving all server components anyway, would it make sense to > then define namespaces per server component below airflow.core. directly > such that a future separation into API server/scheduler/dag parser can > keep a moved structure? > > e.g. moving all API server specific stuff to airflow.core.api. and all > scheduler specific to airflow.core.scheduler. > > Jens > > On 1/5/26 09:17, Amogh Desai wrote: > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
