Thanks TP, I considered this as well. The main concern is dependency weight. The mypy plugins only need mypy itself to run — they don't import anything from airflow-core or task-sdk at runtime. They just reference Airflow's fully qualified names as strings to hook into mypy's type resolution.
If we bundle the plugins into the task SDK, then running mypy checks would pull in the full task-sdk (and transitively airflow-core) as dependencies. For CI environments that only need type checking — like our own CI in the Airflow repo, or users' lightweight linting pipelines — that's a lot of unnecessary overhead. Keeping it as a separate lightweight package means users can just `pip install apache-airflow-mypy` in their CI without installing Airflow itself, which is exactly how most teams use mypy plugins for framework-specific type support (e.g. django-stubs, pydantic mypy plugin, etc.). Hussein On Mon, Mar 23, 2026 at 11:52 PM Tzu-ping Chung via dev < [email protected]> wrote: > Would it be a good idea to release the plugins in the sdk instead, and/or > under the airflow.sdk namespace? I feel that may be a more consistent > interface to users. > > TP > > -- > Sent from my iPhone > > > On 24 Mar 2026, at 05:10, Jens Scheffler <[email protected]> wrote: > > > > Like it! > > > > If somebody has time I also think that the standard "**context" > parameters injected by the Task runner in Tasks would benefit from special > handling such that we can prevent to say: > > > > @task > > def my_task(params: ParamsDict | None = None): > > ... > > > > and mypy accepts > > > > @task > > def my_task(params: ParamsDict): > > ... > > > > (or similar) > > > > Jens > > > >> On 23.03.26 21:57, Hussein Awala wrote: > >> Hi everyone, > >> > >> I’d like to propose releasing the existing MyPy plugins as a standalone > >> package: *apache-airflow-mypy*. > >> > >> > >> *Background* > >> > >> Apache Airflow currently ships two MyPy plugins (decorators and outputs) > >> that improve type checking for DAG authors. > >> > >> At the moment, these plugins live inside the repository but are not > >> published to PyPI. As a result, users who want to benefit from type > >> checking need to manually copy these plugin files into their own > projects. > >> This is what several teams are doing today. > >> > >> > >> *Proposal* > >> > >> Publish *apache-airflow-mypy* as an independently versioned package on > >> PyPI, following SemVer. > >> > >> The package is small and self-contained (two plugins, ~150 lines of > code), > >> which should make it straightforward to maintain. > >> > >> PR: https://github.com/apache/airflow/pull/61422 > >> > >> It includes: > >> > >> - A dedicated package under dev/mypy/ with its own pyproject.toml > >> - A Breeze release command: prepare-mypy-distributions > >> - Release documentation: dev/README_RELEASE_MYPY.md > >> - Tests and Towncrier-based release notes > >> > >> The name *apache-airflow-mypy* has already been reserved on PyPI (thanks > >> Jens!). > >> > >> > >> *What the plugins do* > >> > >> - *outputs plugin* > >> Makes operator.output and @task calls return Any instead of XComArg, > >> allowing DAGs that pass task outputs between tasks to type-check > without > >> errors. > >> - *decorators plugin* > >> Adjusts type signatures for certain Google Cloud decorators (e.g. > >> fallback_to_default_project_id, etc.). > >> > >> > >> *Usage* > >> > >> pip install apache-airflow-mypy > >> > >> Add to mypy.ini: > >> > >> [mypy] > >> plugins = > >> airflow_mypy.plugins.decorators > >> airflow_mypy.plugins.outputs > >> > >> > >> I’m happy to take ownership of the release process for this package. > >> > >> Any thoughts or feedback would be very welcome. > >> > >> Thanks, > >> Hussein > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
