+1 from me for the thought, Agree with Jens on this as well, if we're cleaning up let's also take the opportunity to move them under components too!
-- Regards, Aritra Basu On Mon, 5 Jan 2026, 3:04 pm Rahul Vats, <[email protected]> wrote: > +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] > > > > >
