We were going to have compatibility shims to redirect the imports - with - there are few ways to do it - Ash had a little POC with module loader, but I think it has some potential side effect and I think Ash abandoned the idea and I would personally prefer to use our old PEP-563 mechanism using airflow-core/src/airflow/utils/deprecation_tools.py,
Very nice and small PR to implement if you want to contribute - and since you are testing it now with some existing DAGS it might also be a good test if no redirect has been forgotten J. On Tue, Apr 1, 2025 at 1:32 PM Eugen Kosteev <eu...@kosteev.com> wrote: > Hi everyone. > > I am testing compatibility of Airflow 2 DAGs with Airflow 3, and would like > to discuss this topic. > > I took bunch of DAGs from existing Airflow 2 instances and deployed them to > instance with Airflow 3 (3.0.0b4) and have bunch of import errors: > - ModuleNotFoundError: No module named > 'airflow.operators.python_operator' > - ModuleNotFoundError: No module named 'airflow.operators.bash_operator' > - ImportError: cannot import name 'email_operator' from > 'airflow.operators' > - ModuleNotFoundError: No module named 'airflow.operators.dummy_operator' > > I know that users are supposed to migrate from using "airflow.operators" to > standard/stmp/.. provider packages before upgrading to Airflow 3. > > But I also remember some discussions around keeping old imports work, by > rerouting them to the correct module (similarly as we do in case of > deprecated classes, etc.). > So, it will be very smooth for users to migrate to Airflow 3. > > What is our stand on this? Do we abandon "airflow.operators" usage in DAGs > in Airflow 3 completely? > Or this is something that needs to be done in Airflow 3, but not yet. > > -- > Eugene >
