Those were deprecated 4.5+ years ago: https://github.com/apache/airflow/blob/2.0.0/airflow/operators/python_operator.py
On Tue, 1 Apr 2025 at 21:45, Kaxil Naik <kaxiln...@gmail.com> wrote: > 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 >>> >> >>> > >>> >>
