Well — this year 😂 its 2026 already haha. Happy New Year
On Mon, 5 Jan 2026 at 10:36, Kaxil Naik <[email protected]> wrote: > We should wait to complete the entire decoupling story imo including > AIP-92. Until then there won’t be a any net benefit. So 3.3 would be the > earliest for this — mid next year. > > On Mon, 5 Jan 2026 at 10:01, Pierre Jeambrun <[email protected]> > wrote: > >> Sounds good to me. >> >> Just a technicality, in the api_fastapi folder we already have `core_api` >> (public + UI) and `execution_api`. This sub structure wouldn't make sense >> anymore, `airflow.core.api_fastapi.core_api`. (all 3 are core server >> component I guess) >> >> On Mon, Jan 5, 2026 at 10:49 AM Aritra Basu <[email protected]> >> wrote: >> >> > +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] >> > > > >> > > > >> > > >> > >> >
