Instead handle it via ruff rules AIR2 something On Tue, 1 Apr 2025 at 21:44, Kaxil Naik <kaxiln...@gmail.com> wrote:
> ` - 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 >> >> >> > >> >
