Big +1 to the goal. I would include SDK imports and the provider imports used in Dag files in the requirements, especially when core is installed. Users should be able to import and test their Dags without unnecessary core initialization. Alongside timing targets, we should test that these imports do not initialize the ORM, configure logging, or load plugins unnecessarily.
Each entry point should explicitly initialize the components it needs. CLI help, Dag parsing, task execution, and the scheduler have different requirements, so I would avoid replacing implicit initialization with one mandatory call that initializes everything. Moving core under airflow.core makes sense as a clearer boundary, but I think we should treat the package move and removal of import-time side effects as separate concerns. We need a compatibility plan for existing public imports and existing provider versions (for example <https://github.com/apache/airflow/blob/main/providers/standard/src/airflow/providers/standard/__init__.py#L28>). A lightweight compatibility shim could help during the transition, provided it does not restore implicit initialization. I also agree that isolation is central to this work. Could we identify the specific isolation changes that are prerequisites and which parts can progress in parallel? On Wed, Oct 28, 2026 at 10:41 AM Ash Berlin-Taylor <[email protected]> wrote: > Hi everyone, > > Now that 3.4 is almost here (if you haven’t yet tested the beta2 or, or > the RC due this week, please do it!) I’d like to start a discussion and > “requirements gathering” for something that Jarek, Kaxil and I have been > talking about wanting to do since 3.0, namely: > > Make it so that `import airflow` is fast, and side-effect free. > > The high level idea behind this plan is that “everything” in > apache-airflow-core will that lives under airflow-core/src/airflow/ today > will move to to airflow-core/src/airflow/core/. > > - There will be no airflow/__init__.py anymore (or maybe just a > back-compat shim somewhere) > - Importing airflow will not automatically load settings, providers, > plugins, initialised ORM connections, or configure logging. (The entry > points themselves will need to explicitly call a new fn now) > > As I said, the main goal here is speed, especially for unit tests _of > users_ (Airflow’s own unit tests will need to initialise in most cases I > imagine). > > Does anyone else have any related (or conflicting) changes they’d like to > see? > > -ash > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
