` - ModuleNotFoundError: No module named 'airflow.operators.python_operator'` <-- those paths are Airflow 1.x old
We had already stripped `_operator` from the module names in Airflow 2.0.0 -- so IMO there is no need to keep back-compatibility for something that was working 2 major versions ago On Tue, 1 Apr 2025 at 17:23, Jarek Potiuk <ja...@potiuk.com> wrote: > An example where deprection_tools are still used > > https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/utils/log/__init__.py > > It's rather straightforward = needs a package with __init__.py - only where > you list all the classes and provide redirections. It will > automatically raise deprecation warnings: > > from airflow.utils.deprecation_tools import add_deprecated_classes > > __deprecated_classes = { > "cloudwatch_task_handler": { > "CloudwatchTaskHandler": ( > > > "airflow.providers.amazon.aws.log.cloudwatch_task_handler.CloudwatchTaskHandler" > ), > }, > "es_task_handler": { > "ElasticsearchTaskHandler": ( > > > "airflow.providers.elasticsearch.log.es_task_handler.ElasticsearchTaskHandler" > ), > }, > "gcs_task_handler": { > "GCSTaskHandler": > "airflow.providers.google.cloud.log.gcs_task_handler.GCSTaskHandler", > }, > "s3_task_handler": { > "S3TaskHandler": > "airflow.providers.amazon.aws.log.s3_task_handler.S3TaskHandler", > }, > "stackdriver_task_handler": { > "StackdriverTaskHandler": ( > > "airflow.providers.google > .cloud.log.stackdriver_task_handler.StackdriverTaskHandler" > ), > }, > "wasb_task_handler": { > "WasbTaskHandler": > "airflow.providers.microsoft.azure.log.wasb_task_handler.WasbTaskHandler", > }, > } > > add_deprecated_classes(__deprecated_classes, __name__) > > On Tue, Apr 1, 2025 at 1:49 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > 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 > >> > > >
